Obsidian MCP Server

by Storks

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: v0.1.0
Disambiguation3/5
The tools cover distinct Obsidian operations like file management, plugins, properties, and search, but there is notable overlap in some areas. For example, obsidian_create and obsidian_append/prepend both modify files, and obsidian_rename and obsidian_move both handle file renaming, which could cause confusion. However, descriptions help clarify specific use cases.
Naming Consistency5/5
All tool names follow a consistent 'obsidian_' prefix with snake_case and clear verb_noun patterns, such as obsidian_create, obsidian_read, and obsidian_plugins_list. This uniformity makes the set predictable and easy to navigate, with no deviations in naming conventions.
Tool Count2/5
With 54 tools, the count is excessive for an Obsidian server, leading to a bloated and potentially overwhelming interface. While Obsidian is feature-rich, many tools could be consolidated or omitted without losing functionality, making the set feel heavy and less user-friendly.
Completeness5/5
The tool set provides comprehensive coverage of Obsidian's core features, including file CRUD operations, plugin management, property handling, search, and workspace controls. There are no obvious gaps; agents can perform full lifecycle tasks from creation to deletion and advanced functions like version history and tagging.
Average 2.5/5 across 54 of 54 tools scored. Lowest: 1.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/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. 'Open a file' gives no information about what happens when a file is opened—does it require specific permissions, open in a new tab, modify the file, trigger side effects, or have rate limits? It doesn't even clarify if this is a read-only or mutative operation. For a tool with 4 parameters and no annotation coverage, this is completely inadequate.
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 extremely concise at just three words, which is efficient and front-loaded. However, it's arguably under-specified rather than appropriately concise—every word earns its place, but more words are needed to make the description useful. It lacks the structure to convey necessary details, though it doesn't waste space on redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters, no annotations, no output schema, and many sibling tools), the description is severely incomplete. It doesn't explain the tool's purpose beyond the name, provide usage context, describe behavior, or clarify parameters. For a tool that likely interacts with Obsidian vaults and files, this minimal description fails to equip an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters at all. With 4 parameters (vault, file, path, newtab) and 0% schema description coverage, the schema provides only titles without explanations. The description fails to compensate by explaining what these parameters mean, how they interact (e.g., file vs path), or what defaults apply. This leaves the agent guessing about required inputs and their purposes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Open a file' is a tautology that essentially restates the tool name 'obsidian_open' without adding meaningful specificity. It doesn't specify what type of file (e.g., Obsidian note, markdown file) or what 'open' means in this context (e.g., open in editor, open in viewer). While the verb 'open' is clear, the resource 'file' is too generic given the Obsidian context and sibling tools like obsidian_read, obsidian_create, and obsidian_append that handle files differently.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 obsidian_read (for reading file contents), obsidian_create (for creating files), and obsidian_workspace (for workspace operations), there's no indication of whether this tool opens files for editing, viewing, or another purpose. No context, exclusions, or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get tag info' only indicates a read operation without specifying what information is returned (e.g., structured data, counts, file lists), whether it requires specific permissions, or if there are rate limits. The description fails to disclose any behavioral traits beyond the basic read intent, leaving critical operational details unknown.
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 extremely concise at just three words, which is appropriately brief for a simple-sounding tool. However, this brevity comes at the cost of under-specification—it's too minimal to be helpful. While front-loaded, it lacks the necessary detail to be fully effective, though it avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters with 0% schema coverage, no annotations, no output schema), the description is completely inadequate. It does not explain what the tool returns, how parameters affect behavior, or any operational constraints. For a tool that likely interacts with a note-taking system (Obsidian) and has multiple configuration options, the description fails to provide the minimal context needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the 4 parameters (vault, name, total, verbose) are documented in the schema. The description 'Get tag info' adds no meaning about these parameters—it doesn't explain what 'vault' refers to, what 'name' should contain, or the purpose of 'total' and 'verbose' flags. With zero compensation for the lack of schema documentation, the description fails to provide any parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get tag info' is a tautology that essentially restates the tool name 'obsidian_tag'. It provides a vague purpose without specifying what kind of tag information is retrieved (e.g., metadata, usage statistics, associated files) or how it differs from sibling tools like 'obsidian_tags' (which likely lists tags). The description lacks the specificity needed to distinguish this tool's function from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions. Given the presence of sibling tools like 'obsidian_tags' (which likely lists all tags) and 'obsidian_search' (which might search by tag), the absence of usage guidelines leaves the agent guessing about the appropriate scenarios for invoking this specific tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails completely. It doesn't indicate whether this is a read-only operation, what permissions might be required, whether it's destructive, what format results are returned in, or any rate limits. The description provides no behavioral context beyond the basic query concept.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise - a single 5-word sentence. While this represents severe under-specification, it's not wordy or poorly structured. Every word technically contributes, though the contribution is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, no schema descriptions, no annotations, no output schema), the description is completely inadequate. It doesn't explain what a 'base' is, what kind of query this performs, what results look like, or how parameters work together. For a tool with this level of structural complexity, the description fails to provide the necessary context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about any of the 5 parameters (vault, file, path, view, format), all of which have 0% schema description coverage. The agent must guess what these parameters mean, how they interact, and what values are acceptable. With 5 undocumented parameters and no guidance in the description, this creates significant uncertainty for proper tool invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Query a base and return results' is vague and tautological - it essentially restates the tool name 'obsidian_base_query' without specifying what a 'base' is in this context or what kind of query operation this performs. It doesn't distinguish this tool from sibling tools like obsidian_search or obsidian_files, leaving the agent to guess what specific resource this queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. With numerous sibling tools available (obsidian_search, obsidian_files, obsidian_read, etc.), there's no indication of what makes this tool distinct or when it should be selected over other query/search tools in the Obsidian ecosystem.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but provides none. 'Add a bookmark' doesn't indicate whether this creates a new file, modifies existing files, requires specific permissions, has side effects, or what happens on success/failure. For a tool with 7 parameters and no annotation coverage, this is critically 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 maximally concise at just three words. While severely under-specified, it wastes no words and gets straight to the point. There's no unnecessary elaboration or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no annotations, no output schema, and 0% schema description coverage, the description is completely inadequate. It doesn't explain what the tool actually does beyond the name, provides no parameter guidance, no behavioral context, and no differentiation from sibling tools. This leaves the agent with insufficient information to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'bookmark' but provides zero information about any of the 7 parameters (vault, file, subpath, folder, search, url, title). With 0% schema description coverage, the description fails completely to compensate by explaining what these parameters mean, how they relate to bookmark creation, or which are required/optional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a bookmark' is a tautology that essentially restates the tool name 'obsidian_bookmark'. It doesn't specify what kind of bookmark (file, URL, note location) or what system it operates within (Obsidian vault). While the verb 'add' is clear, the resource 'bookmark' is too vague without context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance about when to use this tool versus alternatives. With 7 sibling tools including 'obsidian_bookmarks' (likely for listing bookmarks) and various file/note manipulation tools, there's no indication of when this specific bookmark-adding tool is appropriate versus other creation or organization tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List bookmarks' gives no information about whether this is a read-only operation, what permissions might be needed, whether it's destructive, what the output format looks like, or any rate limits. For a tool with 3 parameters and no annotation coverage, this is completely inadequate behavioral 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 extremely concise at just two words. While this represents severe under-specification rather than ideal conciseness, from a pure structural perspective it's front-loaded with zero wasted words. Every word earns its place, though there are far too few words to be helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters with 0% schema coverage, no annotations, no output schema, and multiple sibling tools, the description 'List bookmarks' is completely inadequate. It doesn't explain what bookmarks are in this context, how parameters affect the listing, what the output contains, or how this differs from related tools. This fails to provide the minimal context needed for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters at all, while the schema has 3 parameters (vault, total, verbose) with 0% schema description coverage. The schema only provides titles ('Vault', 'Total', 'Verbose') without explaining what these parameters mean or how they affect the listing. The description fails completely to compensate for this gap by adding any parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List bookmarks' is a tautology that essentially restates the tool name 'obsidian_bookmarks'. It provides no additional specificity about what kind of bookmarks are being listed (Obsidian bookmarks? Browser bookmarks?), what format they're in, or what distinguishes this from sibling tools like 'obsidian_bookmark' (singular). The purpose is minimally stated but lacks differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool versus alternatives. With multiple sibling tools in the Obsidian ecosystem (like 'obsidian_search', 'obsidian_files', 'obsidian_tags'), there's no indication whether this is for listing bookmarks within notes, bookmark files, or something else. No context about prerequisites, alternatives, or exclusions is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Open daily note' implies a read or display operation, but it does not specify whether this creates a new note, opens an existing one, requires specific permissions, or has any side effects. For a tool with zero annotation coverage, this minimal description is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, with no wasted language. It is front-loaded and to the point, though this brevity contributes to its inadequacy in other dimensions by omitting necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 undocumented parameters, no annotations, no output schema, and multiple sibling tools), the description is severely incomplete. It does not explain what 'open' entails, how parameters are used, what the output might be, or how it differs from related tools, making it insufficient for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters ('vault' and 'paneType') with 0% description coverage, meaning their purposes are undocumented. The tool description does not mention these parameters at all, failing to compensate for the schema gap. This leaves the agent with no semantic understanding of what inputs are needed or how they affect the tool's behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Open daily note' is a tautology that essentially restates the tool name 'obsidian_daily' without adding meaningful specificity. It mentions the action ('open') and resource ('daily note'), but fails to distinguish this tool from siblings like 'obsidian_daily_read' or 'obsidian_open', leaving the exact purpose unclear beyond the obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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, and with multiple sibling tools related to daily notes (e.g., 'obsidian_daily_append', 'obsidian_daily_read'), this lack of differentiation is a significant gap that could lead to incorrect tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'List or compare versions from file recovery and Sync,' which doesn't reveal whether this is a read-only or mutative operation, what permissions are needed, how results are returned, or any rate limits. For a tool with 6 parameters and no annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence: 'List or compare versions from file recovery and Sync.' It's front-loaded with the core purpose and has no wasted words. While it lacks detail, it is structurally sound and appropriately sized for its content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, no annotations, no output schema), the description is highly incomplete. It doesn't explain what 'versions' refer to, how the tool behaves, what the return values are, or how parameters should be used. This is inadequate for a tool that likely involves version comparison or listing, as the agent lacks essential context to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 6 parameters (vault, file, path, from_, to, filter) have descriptions in the schema. The description adds no meaning beyond the schema—it doesn't explain what these parameters do, how they interact, or provide examples. This leaves the agent guessing about parameter usage, which is inadequate for a tool with multiple inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List or compare versions from file recovery and Sync' states a general purpose but is vague about what specific resource is being acted upon. It mentions 'versions' but doesn't specify whether these are file versions, vault versions, or something else. The verb 'list or compare' is somewhat clear, but it doesn't distinguish this tool from siblings like 'obsidian_history' or 'obsidian_files' that might also deal with versioning or file operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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, or exclusions, and with many sibling tools like 'obsidian_history' and 'obsidian_files' that might overlap, there's no explicit or implied differentiation. This 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.
Behavior1/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. 'Show folder info' gives no insight into whether this is a read-only operation, what permissions are needed, if it has side effects, rate limits, or what the output format looks like. For a tool with 3 parameters and no output schema, this leaves critical behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just two words, with no wasted language. However, this conciseness comes at the cost of under-specification—it's too brief to be helpful. Every word earns its place, but there aren't enough words to convey meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no annotations, no output schema, and many sibling tools), the description is completely inadequate. It doesn't clarify the tool's purpose, usage, behavior, or parameters, making it insufficient for an agent to understand how to invoke it correctly or interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters, while the schema has 3 parameters (vault, path, info) with 0% schema description coverage. 'Show folder info' doesn't explain what these parameters mean, how they interact, or what 'info' refers to. With low schema coverage, the description fails to compensate, leaving parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Show folder info' is a tautology that essentially restates the tool name 'obsidian_folder_info'. It provides a vague verb ('show') but doesn't specify what kind of information is shown (metadata, contents, structure, etc.) or how it differs from sibling tools like 'obsidian_file_info' or 'obsidian_folders'. The purpose is unclear beyond the obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 'obsidian_folders' (likely listing folders), 'obsidian_file_info' (showing file info), and 'obsidian_search' (searching content), there's no indication of this tool's specific context, prerequisites, or exclusions. The agent must guess based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Enable a plugin' implies a mutation operation, but it doesn't describe effects (e.g., whether the plugin becomes active immediately, requires a restart, or affects vault performance), permissions needed, error conditions, or side effects. This is inadequate for a tool with potential system impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, with no wasted language. It's front-loaded with the core action, though this brevity comes at the cost of clarity and completeness. Every sentence (here, a single phrase) earns its place by stating the tool's action, albeit minimally.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with 3 parameters, no annotations, and no output schema), the description is severely incomplete. It lacks purpose differentiation, usage guidelines, behavioral details, parameter explanations, and output information. This is inadequate for enabling a plugin in a system like Obsidian.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the three parameters (vault, id, filter) are documented in the schema. The description adds no information about what these parameters mean, their formats, or how they interact (e.g., 'id' likely identifies the plugin, but this isn't stated). For a tool with undocumented parameters, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Enable a plugin' is a tautology that restates the tool name 'obsidian_plugin_enable' without adding specificity. It doesn't clarify what resource is being enabled (e.g., an Obsidian plugin), distinguish it from sibling tools like 'obsidian_plugin_disable' or 'obsidian_plugin_info', or provide any context about what enabling entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., plugin must be installed), differentiate from sibling tools like 'obsidian_plugin_disable' for disabling plugins, or specify scenarios where enabling is appropriate. The description offers no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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. 'List templates' implies a read-only operation but doesn't specify if it requires permissions, how results are returned (e.g., format, pagination), or any side effects. This is inadequate for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two words, 'List templates,' which is front-loaded and wastes no space. However, this brevity comes at the cost of clarity and completeness, but as per the dimension, it scores high for being succinct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a listing tool with 2 parameters), no annotations, 0% schema coverage, and no output schema, the description is completely inadequate. It doesn't explain what templates are, how to use parameters, or what the output looks like, leaving the agent with insufficient information to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description adds no information about the two parameters (vault and total), such as what they do, their expected values, or how they affect the listing. This fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List templates' restates the tool name 'obsidian_templates' in a slightly different phrasing, making it a tautology. It doesn't specify what kind of templates (e.g., note templates in Obsidian) or provide any distinguishing context from sibling tools like obsidian_files or obsidian_tags, leaving the purpose vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools like obsidian_files, obsidian_search, and obsidian_tags that might overlap in listing content, the description offers no context, prerequisites, or exclusions, leaving the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Show vault info' gives no information about what the tool actually does operationally: whether it returns metadata, statistics, configuration, or something else; whether it has side effects; what permissions are required; or what format the output takes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words. While this leads to under-specification in other dimensions, from a pure conciseness perspective it's maximally efficient with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters, no annotations, no output schema, and 0% schema description coverage, the description is completely inadequate. It doesn't explain what the tool does beyond its name, doesn't document parameters, doesn't provide usage context among many siblings, and doesn't describe behavior or output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for both parameters ('vault' and 'info'), the description provides no information about what these parameters mean, what values they accept, or how they affect the tool's behavior. The description doesn't mention parameters at all, leaving them completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Show vault info' restates the tool name 'obsidian_vault' in slightly different words, making it tautological. It doesn't specify what kind of information is shown or how this differs from sibling tools like 'obsidian_folder_info' or 'obsidian_file_info' that also provide information about Obsidian elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 that provide information (e.g., obsidian_file_info, obsidian_folder_info, obsidian_workspace), there's no indication of what makes this tool unique or when it should be selected over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but provides almost none. 'Load a saved workspace' implies a read operation but doesn't clarify whether this changes application state, what happens if the workspace doesn't exist, whether authentication is required, or what the expected outcome is. For a tool that presumably restores a workspace configuration, this is a significant behavioral information gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise at just 4 words. It's front-loaded with the core action and doesn't waste words. While it's under-specified, it's not verbose or poorly structured. Every word in 'Load a saved workspace' contributes to the basic meaning, even if that meaning is insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of workspace operations, no annotations, no output schema, and 0% schema description coverage, the description is completely inadequate. It doesn't explain what a 'workspace' is in this context, what gets loaded, what the expected outcome is, or any behavioral characteristics. For a tool that presumably restores application state, this leaves critical questions unanswered about side effects, error conditions, and return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides zero information about parameters, while the schema has 0% description coverage. With 2 parameters (one required 'name', one optional 'vault'), the description doesn't explain what these parameters mean, what values they accept, or how they affect the loading operation. The schema only provides titles 'Vault' and 'Name' without descriptions, so the description fails to compensate for the complete lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Load a saved workspace' is a tautology that essentially restates the tool name 'obsidian_workspace_load'. It specifies the verb 'load' and resource 'saved workspace', but doesn't clarify what 'workspace' means in this context or what the loading operation actually does. While it distinguishes from some siblings like 'obsidian_workspace_save', it doesn't clearly differentiate from other workspace-related tools like 'obsidian_workspace' or 'obsidian_workspaces'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a saved workspace first), doesn't specify when this tool is appropriate versus other workspace tools, and offers no context about typical use cases. Given the sibling tools include 'obsidian_workspace', 'obsidian_workspaces', and 'obsidian_workspace_save', the lack of differentiation is particularly problematic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Get plugin info' implies a read-only operation but does not specify permissions, rate limits, side effects, or output format. It lacks critical details like whether it retrieves metadata, status, or configuration, making it inadequate for a tool with no structured safety hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence, 'Get plugin info.', which is front-loaded and wastes no words. While under-specified, it is structurally efficient and earns full marks for brevity and clarity within its limited scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, no output schema, and two parameters (one required), the description is severely incomplete. It does not explain what 'plugin info' entails, how to use parameters, or behavioral traits, making it inadequate for effective tool invocation in a context with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions no parameters, failing to explain the required 'id' (e.g., plugin identifier) or optional 'vault' (e.g., target vault). This leaves semantics unclear, though it avoids contradiction with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get plugin info' restates the tool name 'obsidian_plugin_info' with minimal elaboration, making it tautological. It specifies the verb 'Get' and resource 'plugin info' but lacks detail on what 'info' includes or how it differs from sibling tools like 'obsidian_plugins' or 'obsidian_plugins_enabled', failing to provide meaningful differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. With sibling tools like 'obsidian_plugins' (likely listing plugins) and 'obsidian_plugins_enabled' (likely showing enabled plugins), there is no indication of context, prerequisites, or exclusions, leaving the agent without usage 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 the full burden of behavioral disclosure. 'Show or update a task' implies both read and write capabilities, but it doesn't specify permissions needed, side effects, rate limits, or what 'update' entails (e.g., toggling status). This leaves critical behavioral traits unclear for a tool with potential mutations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence 'Show or update a task.' It's front-loaded and wastes no words, though this brevity contributes to underspecification rather than clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no annotations, no output schema), the description is completely inadequate. It doesn't explain what the tool does in detail, how to use parameters, what it returns, or how it fits with siblings, making it insufficient for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters, while the input schema has 10 parameters with 0% description coverage (only titles like 'Vault', 'Ref'). This fails to compensate for the schema's lack of detail, leaving all parameters semantically undefined and unusable without guesswork.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Show or update a task' states a vague purpose with two possible actions but lacks specificity about what resource it operates on (Obsidian tasks) and how it differs from sibling tools like obsidian_tasks. It's better than a tautology but doesn't clearly distinguish the tool's unique function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 obsidian_tasks or other task-related tools. There's no mention of prerequisites, context, or exclusions, leaving the agent with no usage 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. 'List tasks' implies a read-only operation, but it doesn't specify permissions needed, rate limits, pagination, or what happens if parameters conflict. For a tool with 10 parameters and no annotation coverage, this leaves significant behavioral gaps unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized for a basic listing tool, though it may be too brief given the complexity of parameters. Every word earns its place by stating the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (10 parameters, 0% schema coverage, no annotations, no output schema), the description is completely inadequate. It doesn't explain what tasks are, how they're defined in Obsidian, what the output looks like, or how parameters interact. For a tool with this level of undocumented complexity, a single sentence is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about the 10 parameters, and schema description coverage is 0%. Parameters like 'vault', 'file', 'status', 'done', 'todo', etc., are entirely undocumented in both the schema and description. The description fails to compensate for the lack of schema documentation, leaving parameter meanings unclear.
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 'List tasks in the vault' clearly states the verb ('List') and resource ('tasks'), but it's vague about scope and lacks sibling differentiation. It doesn't specify whether it lists all tasks or filtered tasks, and with siblings like 'obsidian_task' (singular), it doesn't clarify the distinction between listing multiple tasks vs. a single task operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools (e.g., 'obsidian_task', 'obsidian_search'), the description doesn't indicate whether this is for task-specific queries, how it differs from general search, or any prerequisites like vault access. Usage is implied by the name 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 the full burden of behavioral disclosure. 'Create or overwrite a file' implies a write operation that can be destructive (overwrites), but it doesn't specify permissions needed, whether changes are reversible, rate limits, or what happens on success/failure. For a mutation tool with 8 parameters and no annotation coverage, this is a significant gap in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 4 words ('Create or overwrite a file'), with zero wasted words. It's front-loaded with the core action, though this brevity comes at the cost of completeness. Every word earns its place by conveying the essential operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, no annotations, no output schema, and 0% schema description coverage), the description is incomplete. It doesn't explain parameter usage, behavioral details, or output expectations. For a file creation/overwrite tool in a rich ecosystem like Obsidian with many sibling tools, more context is needed to guide proper usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 8 parameters have descriptions in the schema. The tool description provides no information about any parameters—not explaining what 'vault', 'name', 'path', 'content', 'template', 'overwrite', 'open', or 'newtab' mean or how they interact. With 8 undocumented parameters, the description fails to compensate for the schema's lack of documentation.
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 'Create or overwrite a file' states a clear verb+resource combination, specifying both creation and overwriting actions. However, it doesn't distinguish this tool from sibling tools like obsidian_base_create or obsidian_daily, which may also create files in specific contexts. The purpose is understandable but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools like obsidian_append, obsidian_prepend, obsidian_read, and obsidian_delete, there's no indication of when creation/overwriting is appropriate versus appending, reading, or deleting. No prerequisites or context for usage are mentioned.
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 'shows' info (implying read-only). It lacks behavioral details like whether it requires specific permissions, what happens if the file doesn't exist, if it's cached, or what format the info is returned in. Minimal disclosure 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 very concise with just one short phrase, front-loaded with the main purpose. No wasted words, though it could benefit from slightly more detail given the lack of annotations and schema coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'file info' includes, how parameters work, or the return format. For a tool with this complexity and lack of structured data, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 but adds no parameter information. It doesn't explain what 'vault', 'file', or 'path' mean, their relationships, or how they interact with the default behavior. The description fails to provide meaning beyond the bare schema.
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 shows file info, which is a clear verb+resource combination, but it's vague about what 'file info' includes (e.g., metadata, properties, size). It distinguishes from siblings by specifying 'default: active file', but doesn't explicitly differentiate from similar tools like obsidian_files or obsidian_folder_info.
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 minimal guidance with 'default: active file', implying it can be used without parameters, but offers no explicit when-to-use advice, alternatives, or exclusions compared to siblings. No mention of prerequisites or when to choose this over other file-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a list operation, implying it's read-only and non-destructive, but doesn't address permissions, rate limits, output format, or error conditions. For a tool with three parameters and 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, with no wasted language. It's front-loaded with the core purpose and contains no unnecessary elaboration, making it efficient for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain what the parameters do, what the return value looks like, or any behavioral constraints. For a tool with this complexity level, the description provides insufficient context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning none of the three parameters (vault, filter, versions) are documented in the schema. The description provides no information about these parameters—not even mentioning their existence—failing to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List enabled plugins' clearly states the verb ('List') and resource ('enabled plugins'), providing a basic understanding of the tool's function. However, it doesn't distinguish this tool from its sibling 'obsidian_plugins' (which likely lists all plugins), making the purpose somewhat vague in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'obsidian_plugins' (for listing all plugins) or 'obsidian_plugin_info' (for detailed plugin information), 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'prepend content after frontmatter' which implies a write/mutation operation, but doesn't disclose critical behavioral traits: whether this modifies files permanently, what permissions are needed, how it handles errors, or what happens to existing content. The 'default: active file' hint is minimal context.
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 very brief (one phrase) and front-loaded with the core action. However, it's arguably too concise given the complexity—5 parameters with 0% schema coverage and no annotations warrant more explanation. The structure is simple but under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain the tool's behavior, parameter usage, return values, or error handling. For a mutation tool in a rich ecosystem like Obsidian with many siblings, this leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only indirectly references parameters via 'default: active file' (hinting at 'file' parameter) but doesn't explain any of the 5 parameters' purposes, relationships, or semantics. No details on what 'vault', 'path', 'content', or 'inline' mean or how they interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('prepend content') and target ('after frontmatter'), which provides a basic purpose. However, it doesn't specify what resource is being modified (Obsidian notes/files) or differentiate from sibling tools like 'obsidian_append' or 'obsidian_daily_prepend'. The phrase 'default: active file' adds some context but doesn't fully clarify the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description mentions 'default: active file' which implies it can target other files, but doesn't explain when to use parameters like 'vault', 'file', or 'path' versus the default. No comparison to sibling tools like 'obsidian_append' or 'obsidian_daily_prepend' is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it's a creation tool, implying mutation, but doesn't disclose any behavioral traits like permissions needed, whether it overwrites existing items, error conditions, or what happens on success. For a mutation tool with 8 parameters and no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's appropriately sized for a basic tool description and front-loaded with the core action. Every word earns its place, though the brevity contributes to the lack of detail in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, mutation tool, no annotations, no output schema), the description is incomplete. It doesn't explain what a 'base' or 'item' is, how parameters interact, what the tool returns, or error handling. For a tool with this many undocumented parameters and no structured guidance, the description fails to provide adequate context for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides no information about any of the 8 parameters (vault, file, path, view, name, content, open, newtab), their purposes, relationships, or required combinations. The description adds no value beyond the schema's property titles, failing to address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('create') and target ('new item in a base'), which provides a basic purpose. However, it's vague about what constitutes an 'item' or 'base' in the Obsidian context, and doesn't distinguish this from sibling tools like 'obsidian_create' or 'obsidian_daily_create' (implied by daily tools). It's not tautological but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools for creating or managing content (e.g., 'obsidian_create', 'obsidian_daily', 'obsidian_append'), the description offers no context about when this specific 'base' creation is appropriate, leaving the agent to guess based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('append') but doesn't explain what happens if the daily note doesn't exist, how content is formatted (e.g., line breaks, Markdown), or whether the operation is idempotent. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, clearly stating the core action without unnecessary details, earning a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool with 5 parameters), no annotations, and no output schema, the description is incomplete. It lacks details on behavior, parameter usage, error handling, and return values, making it inadequate for an AI agent to use the tool effectively without additional context or trial-and-error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters, but it mentions none. With 5 parameters (1 required, 4 optional), the description adds no meaning beyond what the schema's property names imply (e.g., 'content' is the text to append, but format or constraints are unclear). This fails to address the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Append content to daily note' clearly states the verb ('append') and resource ('daily note'), but it's vague about what 'daily note' specifically refers to in the Obsidian context. It doesn't distinguish this tool from its sibling 'obsidian_daily_prepend' beyond the action direction, nor from 'obsidian_append' which might append to other note types.
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 'obsidian_daily_prepend' (for prepending) or 'obsidian_daily_read' (for reading). It doesn't mention prerequisites, such as whether a daily note must exist or how it's identified, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'prepend' but doesn't disclose behavioral traits such as whether this modifies files permanently, requires specific permissions, handles errors, or interacts with Obsidian's UI. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for its limited content, though this conciseness comes at the cost of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool with 5 parameters), no annotations, no output schema, and 0% schema coverage, the description is incomplete. It lacks essential details about behavior, parameters, and context, making it insufficient for safe and effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter semantics beyond the tool name. With 5 parameters (vault, content, paneType, inline, open) and only 'content' required, the description doesn't explain what these mean, their formats, or default behaviors, failing to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Prepend content to daily note' clearly states the action (prepend) and target (daily note), which is better than a tautology. However, it doesn't specify what distinguishes this from sibling tools like 'obsidian_daily_append' or 'obsidian_prepend', leaving the scope vague regarding daily notes specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'obsidian_daily_append' (append to daily note) and 'obsidian_prepend' (prepend to general notes), there's no indication of context, prerequisites, or exclusions, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Disable a plugin' implies a mutation action but lacks details on effects (e.g., whether it's reversible, requires restart, affects other plugins, or has permissions). It doesn't cover error handling, rate limits, or return values, leaving significant gaps for a tool that modifies system state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence ('Disable a plugin.'), which is front-loaded and wastes no words. For a simple action, this brevity is appropriate, though it may sacrifice clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool with 3 parameters, 0% schema coverage, no annotations, and no output schema), the description is incomplete. It doesn't explain the tool's behavior, parameters, or output, leaving the agent with insufficient information to use it correctly beyond the basic action implied by the name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter documentation. The description adds no information about the three parameters ('vault', 'id', 'filter'), such as what 'id' refers to (plugin name or identifier), how 'vault' is specified, or what 'filter' does. This fails to compensate 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Disable a plugin' clearly states the verb ('disable') and resource ('a plugin'), making the purpose understandable. However, it doesn't specify what 'disable' means operationally (e.g., deactivation vs. uninstallation) or differentiate from sibling tools like 'obsidian_plugin_enable' beyond the obvious verb difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., whether the plugin must be enabled first), exclusions, or related tools like 'obsidian_plugin_enable' for toggling states. Usage is implied only by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Show workspace tree' implies a read-only operation, but it doesn't specify what 'workspace tree' means in this context, whether it requires specific permissions, what format the output takes, or any limitations. The description provides minimal behavioral 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, with no wasted language. It's front-loaded with the core action and object, making it easy to parse quickly. This is an example of appropriate minimalism when the tool name itself provides additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters (0% documented in schema), no annotations, no output schema, and many similar sibling tools, the description is inadequate. It doesn't explain what 'workspace tree' means, how parameters affect the output, what the return format is, or when to choose this over other workspace-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for both parameters (vault and ids), the description provides no information about what these parameters mean or how they affect the operation. 'Show workspace tree' doesn't mention parameters at all, leaving the agent to guess about when and how to use vault specification or ids inclusion.
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 'Show workspace tree' clearly indicates a read/display operation on workspace data, which is specific enough to understand the basic function. However, it doesn't distinguish this tool from similar siblings like 'obsidian_workspaces' (plural) or 'obsidian_workspace_load', leaving ambiguity about what makes this tool unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools related to workspaces (obsidian_workspaces, obsidian_workspace_load, obsidian_workspace_save), the description offers no context about whether this is for viewing current workspace structure, listing available workspaces, or some other specific use case.
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 indicates deletion behavior and default trash placement, but fails to address critical aspects like permissions required, whether deletion is reversible from trash, error handling for non-existent files, or what the tool returns upon success/failure. This leaves significant gaps for a destructive 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 extremely concise (8 words) and front-loaded with the core action. Every word serves a purpose, though it could benefit from slightly more structure (e.g., separating defaults from main action). There's no wasted verbiage, making it efficient despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with 4 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It covers basic functionality but misses critical context about parameters, return values, error conditions, and behavioral nuances. The agent would struggle to use this tool correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for all 4 parameters, the description must compensate but only partially does so. It implies 'file' parameter usage ('active file') and hints at 'permanent' behavior ('trash by default'), but doesn't explain 'vault' or 'path' parameters at all. This leaves half the parameters undocumented and the others only superficially covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete a file') and specifies the default behavior ('default: active file, trash by default'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'obsidian_move' or 'obsidian_rename' that also modify files, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance by mentioning defaults, but offers no explicit advice on when to use this tool versus alternatives (e.g., 'obsidian_move' for relocation or 'obsidian_rename' for renaming). There's no mention of prerequisites, error conditions, or typical use cases, leaving usage context largely implied.
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 output format but doesn't describe important behavioral aspects like whether this is a read-only operation, performance characteristics, error conditions, or how it handles the optional parameters. The description is too minimal for a tool with 6 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - just one sentence that efficiently communicates the core functionality and output format. However, this conciseness comes at the cost of completeness, as it omits important information about parameters and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain the parameters, doesn't provide usage guidance relative to siblings, and doesn't describe behavioral aspects like whether it's a read operation or has performance considerations. The output format mention is helpful but insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for all 6 parameters, the description provides no information about what any of the parameters mean or how they affect the search. The description doesn't mention 'vault', 'query', 'path', 'limit', 'format', or 'case' parameters at all, leaving the agent with no guidance beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Search with matching line context') and the output format ('grep-style path:line: text output'), which distinguishes it from generic search tools. However, it doesn't explicitly differentiate from its sibling 'obsidian_search' tool, which appears to be a similar search function without the line context feature.
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 'obsidian_search' or other search-related siblings. There's no mention of specific use cases, prerequisites, or exclusions that would help an agent choose between this and other tools in the server.
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 appends content, implying a mutation operation, but lacks details on permissions, error handling, file creation if missing, or effects on existing content. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single, clear sentence with no wasted words. It is front-loaded with the core action and includes a useful parenthetical note about default behavior, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, mutation operation), lack of annotations, and no output schema, the description is insufficient. It fails to explain parameter roles, behavioral traits like error conditions, or what the tool returns, leaving the agent with inadequate information to use the tool effectively beyond basic intent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only mentions the 'file' parameter implicitly via the default active file, but does not explain the purpose of 'vault', 'path', 'content', or 'inline'. With 5 parameters and no schema descriptions, the description adds minimal value beyond hinting at one parameter's default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Append content') and target ('to a file'), with the specific detail that it defaults to the active file. It distinguishes from sibling tools like 'obsidian_prepend' by specifying the append operation, though it doesn't explicitly contrast with other file-modification tools like 'obsidian_create' or 'obsidian_delete'.
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 minimal guidance by noting the default behavior (active file), but offers no explicit advice on when to use this tool versus alternatives like 'obsidian_prepend', 'obsidian_create', or 'obsidian_daily_append'. There are no usage prerequisites, exclusions, or comparisons to sibling tools mentioned.
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 this is a read operation, which implies it's non-destructive, but doesn't clarify what 'daily note contents' means (e.g., current date vs. specified date), how it handles missing notes, or any permissions/rate limits. This leaves significant 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 extremely concise ('Read daily note contents.') with no wasted words. It's front-loaded and gets straight to the point, making it efficient for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (reading daily notes in Obsidian), lack of annotations, no output schema, and undocumented parameters, the description is incomplete. It doesn't explain what 'daily note contents' includes, how dates are determined, error handling, or return format, leaving too many open questions for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter ('vault') with 0% description coverage, and the tool description provides no information about parameters. This leaves the 'vault' parameter completely undocumented in both schema and description, failing to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read') and target ('daily note contents'), which is specific and unambiguous. However, it doesn't distinguish this tool from similar siblings like 'obsidian_read' or 'obsidian_daily', leaving some ambiguity about its unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'obsidian_read', 'obsidian_daily', and 'obsidian_daily_path', there's no indication of how this tool differs or when it should be preferred, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 'List files in the vault' implies a read-only operation, but it doesn't specify if it requires permissions, how it handles large vaults (e.g., pagination or performance limits), or what the output format looks like (e.g., list of file names, paths, or metadata). This leaves significant gaps for an agent to understand 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 extremely concise with a single sentence 'List files in the vault', which is front-loaded and wastes no words. It efficiently conveys the core purpose without unnecessary details, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (4 parameters with no schema descriptions, no annotations, no output schema, and many sibling tools), the description is incomplete. It doesn't explain parameter usage, behavioral constraints, or how it differs from alternatives. For a tool with multiple optional parameters and no structured guidance, this leaves too much ambiguity for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters (vault, folder, ext, total) with 0% schema description coverage, meaning none are documented in the schema. The description 'List files in the vault' only implies the 'vault' parameter and doesn't mention 'folder', 'ext', or 'total', leaving most parameters unexplained. This fails to compensate for the low coverage, adding minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List files in the vault' clearly states the action (list) and resource (files in the vault), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'obsidian_folders' or 'obsidian_search', which might also list or retrieve files in different contexts, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools available (e.g., 'obsidian_search', 'obsidian_folders'), there's no indication of whether this tool is for basic listing, filtered searches, or other specific use cases. It's a generic statement without 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. 'List folders' implies a read-only operation, but it doesn't disclose behavioral traits such as whether it requires specific permissions, how it handles large vaults (e.g., pagination or performance limits), what the output format is (e.g., list of strings or objects), or error conditions. The description is minimal and misses key operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to scan and understand quickly. No unnecessary details or redundancy are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a tool with 3 parameters and no output schema), the description is incomplete. It lacks parameter explanations, usage context, and behavioral details. Without annotations or an output schema, the description should provide more guidance on what the tool returns and how to use it effectively, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The description adds no information about the three parameters (vault, folder, total), leaving their purposes and usage completely undocumented. For example, it's unclear if 'folder' filters results or specifies a starting path, or what 'total' controls. The description fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List folders in the vault' clearly states the action (list) and resource (folders in the vault). It distinguishes from siblings like obsidian_files (which lists files) and obsidian_vault (which might manage vaults), but doesn't explicitly differentiate from obsidian_folder_info (which could provide details about a specific folder). 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. With siblings like obsidian_files (for files), obsidian_search (for searching), and obsidian_folder_info (for folder details), there's no indication of when listing folders is preferred over other methods. It lacks context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'List versions' which implies a read-only operation, but doesn't disclose behavioral traits such as whether it requires specific permissions, how versions are retrieved (e.g., from a recovery system), what the output format is, or any rate limits. This leaves significant gaps for an agent to understand 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 with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes directly to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters with 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain parameter usage, output format, or behavioral context. For a tool that likely interacts with file versioning in a note-taking app, more details are needed to guide effective use by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate by explaining parameters. It mentions 'file recovery' but doesn't clarify the three parameters (vault, file, path) or their roles (e.g., whether 'file' and 'path' are alternatives, what 'vault' refers to). The description adds minimal semantic value beyond the schema's titles.
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 ('List versions') and the resource ('from file recovery'), which is specific and informative. It doesn't explicitly differentiate from sibling tools like 'obsidian_diff' or 'obsidian_file_info', which might also involve file history or versions, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'obsidian_diff' (which might show differences between versions) or 'obsidian_file_info' (which could include version details), there's no indication of context, prerequisites, or exclusions for using 'obsidian_history'.
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 offers minimal behavioral insight. It implies mutation ('Move or rename') but doesn't disclose critical details like whether the operation is destructive, requires specific permissions, handles errors (e.g., if file doesn't exist), or what happens to links/references. 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?
Extremely concise and front-loaded in a single sentence with no wasted words. Every part ('Move or rename a file', 'default: active file') adds value, making it efficient despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 4 parameters (0% schema coverage), no annotations, and no output schema, the description is incomplete. It lacks details on behavior, parameter usage, error handling, and output format, leaving the agent with insufficient context to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds minimal parameter context. It hints at 'file' (default: active file) and implies 'to' as destination, but doesn't explain the purpose of 'vault', 'path', or how parameters interact (e.g., if 'file' is null, what 'path' does). With 4 parameters undocumented, this is inadequate.
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 ('Move or rename') and resource ('a file'), with a specific default behavior ('default: active file'). It distinguishes from siblings like obsidian_rename by covering both move and rename operations, though it doesn't explicitly contrast with obsidian_rename.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like obsidian_rename or obsidian_create. The description mentions a default (active file) but doesn't explain when to override defaults or provide any context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool 'shows' headings, implying a read-only operation, but doesn't specify if this requires file access permissions, how headings are formatted (e.g., as a list or structured output), or any error handling (e.g., if no file is open). This lack of detail is a significant gap for a tool with multiple parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words, making it easy to parse and front-loaded with the core purpose. Every part of the sentence contributes directly to understanding the tool's function, achieving optimal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters with 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain what the tool returns (e.g., a list of headings, their levels, or a formatted outline), how parameters interact, or any behavioral nuances. This leaves the agent with insufficient information to use the tool effectively beyond a basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'current file', which loosely relates to the 'file' or 'path' parameters, but it doesn't explain the purpose of any of the 5 parameters (vault, file, path, format, total), all of which have 0% schema description coverage. For example, it's unclear what 'format' or 'total' do, leaving the agent to guess based on titles alone. This fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 ('Show') and resource ('headings for the current file'), making it easy to understand what the tool does. It doesn't explicitly differentiate from sibling tools like 'obsidian_read' or 'obsidian_file_info', which might also provide file content or metadata, but the focus on headings is clear.
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, such as requiring an open file or specific context, nor does it compare to siblings like 'obsidian_read' (which might show full content) or 'obsidian_search' (which could find headings). This leaves the agent without explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Install' implies a write/mutation operation, but the description doesn't disclose whether this requires specific permissions, if it's destructive (e.g., overwrites existing plugins), what happens on failure, or any rate limits. It lacks essential context for safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple tool and front-loaded with the core action, though its brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a mutation tool with 3 parameters), lack of annotations, 0% schema coverage, and no output schema, the description is incomplete. It doesn't explain the tool's behavior, parameters, or expected outcomes, leaving critical gaps for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 3 parameters (vault, id, enable) are documented in the schema. The description adds no parameter information beyond the tool name, failing to explain what 'id' refers to (e.g., plugin identifier), what 'vault' means, or the purpose of 'enable'. It doesn't compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Install') and resource ('a community plugin'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling plugin tools like 'obsidian_plugin_disable', 'obsidian_plugin_enable', or 'obsidian_plugin_info', which all operate on plugins but with 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 (e.g., whether the plugin must be available in a repository), when not to use it (e.g., if a plugin is already installed), or refer to sibling tools like 'obsidian_plugin_disable' for related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Reload' implies a mutation operation that restarts the plugin, but the description doesn't specify whether this requires specific permissions, whether it's destructive to plugin state, what happens if the plugin fails to reload, or what the expected outcome is. The '(for developers)' hint adds minimal context but insufficient behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 5 words, with zero wasted language. It's front-loaded with the core action and includes a contextual hint. Every word earns its place, making it efficient despite being under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain what 'reload' means operationally, what parameters are needed, what happens during execution, or what to expect as a result. The '(for developers)' hint is insufficient compensation for these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. The description provides no information about the 'id' or 'vault' parameters - it doesn't explain what plugin ID format is expected, what vault parameter does, or whether vault is required. With 2 parameters completely undocumented, the description adds zero parameter semantics.
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 ('Reload') and target ('a plugin'), making the purpose understandable. It distinguishes from siblings like obsidian_plugin_disable/enable/install/info by specifying the reload action. However, it doesn't specify what 'reload' entails operationally (e.g., restarting plugin without restarting Obsidian).
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 includes '(for developers)' which provides some context about the intended user, but offers no guidance on when to use this tool versus alternatives like obsidian_plugin_disable/enable, or prerequisites for usage. No explicit when/when-not statements or named alternatives 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?
No annotations are provided, so the description carries the full burden. It states the tool lists installed plugins, implying a read-only operation, but doesn't disclose behavioral traits such as whether it requires specific permissions, how it handles errors, or what the output format looks like (e.g., list structure, pagination). This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a simple tool and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no annotations, no output schema), the description is incomplete. It lacks parameter explanations, behavioral context, and output details, making it insufficient for an agent to use the tool effectively without additional inference or trial-and-error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description adds no information about the three parameters (vault, filter, versions), leaving their purposes, formats, and effects completely undocumented. This fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('installed plugins'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'obsidian_plugin_info' or 'obsidian_plugins_enabled', which might offer related 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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention sibling tools like 'obsidian_plugin_info' (for details on a specific plugin) or 'obsidian_plugins_enabled' (which might list only enabled plugins), leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'List properties' implies a read-only operation, but the description doesn't specify whether this requires specific permissions, what format the output takes, whether results are paginated, or if there are rate limits. For a tool with 9 parameters and no annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 4 words, front-loading the core purpose without any wasted words. Every word earns its place, and there's no unnecessary elaboration. This is appropriate conciseness for a tool description, though it may be too brief for adequate completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, 0% schema coverage, no annotations, no output schema), the description is severely incomplete. It doesn't explain what 'properties' means in this context, how parameters interact, what the output format is, or any behavioral constraints. For a tool with this level of parameter complexity and zero structured documentation, the description should do much more to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 9 parameters and 0% schema description coverage, the schema provides only parameter names and types without any semantic meaning. The description 'List properties in the vault' gives no information about what any of the parameters (vault, file, path, name, sort, format, total, counts, active) actually do or how they affect the listing. This leaves the agent guessing about parameter purposes and relationships.
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 'List properties in the vault' clearly states the verb ('List') and resource ('properties in the vault'), making the purpose immediately understandable. It distinguishes this as a listing/querying operation rather than a mutation tool like 'obsidian_property_set' or 'obsidian_property_remove'. However, it doesn't specify what kind of properties (e.g., frontmatter, metadata) or differentiate from similar query tools like 'obsidian_search'.
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 'obsidian_property_read', 'obsidian_search', and 'obsidian_files', there's no indication of when this specific property listing tool is appropriate versus other query or read operations. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool reads a property value, implying a read-only operation, but doesn't specify error handling (e.g., if the property or file doesn't exist), return format, or any side effects. This leaves gaps in understanding how the tool behaves in edge cases, making it insufficient for safe agent invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence that front-loads the core action ('Read a property value from a file') and includes a helpful note on defaults. There is no wasted language, making it efficient and easy to parse, though this brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a property-reading tool with 4 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks details on parameter interactions, error conditions, and return values, which are crucial for an agent to use this tool effectively in a file system context with siblings like 'obsidian_property_set'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It only implies the 'file' parameter through 'default: active file' and mentions 'property value' without clarifying the 'name' parameter. Key parameters like 'vault' and 'path' are undocumented, leaving their purpose ambiguous. This fails to add meaningful semantics 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 action ('Read a property value') and resource ('from a file'), making the purpose understandable. It distinguishes this tool from siblings like 'obsidian_property_set' or 'obsidian_property_remove' by focusing on reading rather than modifying properties. However, it doesn't explicitly differentiate from 'obsidian_properties' (which might list all properties) or 'obsidian_read' (which might read file content), 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 minimal guidance by noting the default behavior ('default: active file'), but it lacks explicit instructions on when to use this tool versus alternatives like 'obsidian_properties' or 'obsidian_read'. No context about prerequisites, such as file existence or property formatting, is mentioned, leaving usage unclear in complex scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic action. It doesn't disclose critical behaviors: whether this overwrites existing properties, requires file write permissions, handles errors (e.g., invalid file), or returns any output. For a mutation tool with 6 parameters, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste, front-loading the core action. It's appropriately sized for a simple tool, though brevity contributes to gaps in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, no output schema, and 6 parameters, the description is incomplete. It lacks details on mutation effects, error handling, parameter usage, and output, making it insufficient for safe and effective tool invocation in a complex Obsidian context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter details. It implies 'file' parameter usage with 'default: active file', but doesn't explain other parameters (vault, name, value, type, path) or their relationships (e.g., file vs. path). This leaves most parameters undocumented.
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 ('Set a property') and target ('on a file'), with a specific default behavior ('default: active file'). It distinguishes from obvious siblings like 'obsidian_property_read' and 'obsidian_property_remove' by specifying a write operation, though it doesn't explicitly differentiate from all mutation tools like 'obsidian_create' or 'obsidian_append'.
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 minimal guidance with the default file behavior, but lacks explicit when-to-use rules, prerequisites (e.g., file must exist), or alternatives (e.g., when to use 'obsidian_property_remove' instead). No context on sibling tools like 'obsidian_properties' (list properties) is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Rename a file' implies a mutation operation, but it doesn't describe permissions needed, whether renames are reversible, error conditions (e.g., if file doesn't exist), or side effects. The default behavior hint is helpful but insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with zero wasted words - a single phrase that's front-loaded with the core purpose. Every word earns its place, making it easy to parse quickly despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 4 parameters, 0% schema coverage, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens during renaming, how parameters interact, what errors might occur, or what the tool returns. The default behavior hint is useful but doesn't compensate for the significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It only mentions 'default: active file' which relates to the 'file' parameter, but doesn't explain the four parameters (vault, file, path, name) or their relationships. The required 'name' parameter gets no explanation beyond the schema's title.
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: 'Rename a file' specifies the verb and resource. It distinguishes from siblings like obsidian_move (which moves files) and obsidian_create (which creates files), though it doesn't explicitly mention these alternatives. The 'default: active file' adds useful context but doesn't fully differentiate from all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: 'default: active file' implies usage when no file is specified, but offers no explicit when-to-use rules, alternatives (like obsidian_move for moving files), prerequisites, or exclusions. It lacks context on when this tool is preferred over other file modification tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the return type ('matching file paths') but doesn't describe important behavioral aspects like whether this is a read-only operation (implied but not stated), whether it supports fuzzy matching, what happens with invalid queries, whether results are paginated, or any performance characteristics. For a search tool with 7 parameters, this is insufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just two sentences with zero wasted words. It's front-loaded with the core purpose and follows with the return value. Every word earns its place, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 7 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain parameter usage, behavioral constraints, or return format details beyond 'matching file paths'. Given the complexity implied by 7 parameters and the lack of structured documentation elsewhere, the description should provide more context about 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 7 parameters, the description provides no information about any parameters. It doesn't explain what 'vault', 'path', 'limit', 'format', 'total', or 'case' mean, or how they affect the search. The description mentions 'vault' and 'text' search generally but doesn't map these to specific parameters or explain their semantics.
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: 'Search vault for text' specifies the verb (search) and resource (vault text), and 'Returns matching file paths' clarifies the output. However, it doesn't explicitly differentiate from sibling tools like 'obsidian_search_context' or 'obsidian_base_query', which likely have overlapping search 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. With multiple search-related siblings (obsidian_search_context, obsidian_base_query, obsidian_tags, etc.), there's no indication of what makes this tool distinct or when it's preferred over others. The description only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'List tags' implies a read-only operation, but it doesn't specify whether this is a simple enumeration or includes metadata like counts or sorting. It lacks details on permissions, rate limits, or what happens with invalid inputs. The description is too minimal for a tool with 7 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core purpose and avoids unnecessary elaboration. This is an example of efficient communication, though it may be overly concise given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no annotations, and no output schema, the description is severely incomplete. It doesn't explain what the tool returns (e.g., a list of tag names, counts, or structured data), how parameters interact, or error conditions. The agent lacks sufficient context to use this tool effectively beyond basic guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all 7 parameters. 'List tags in the vault' only hints at the 'vault' parameter and vaguely suggests scope. It doesn't explain what 'file', 'path', 'sort', 'total', 'counts', or 'active' do, leaving most parameters undocumented. This is inadequate given the parameter complexity.
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 ('List') and resource ('tags in the vault'), making the purpose immediately understandable. It distinguishes itself from siblings like 'obsidian_tag' (singular) by focusing on listing multiple tags. However, it doesn't specify whether this lists all tags globally or filters them, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'obsidian_tag' or 'obsidian_search'. There's no mention of prerequisites, context, or typical use cases. The agent must infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it 'lists' unresolved links, implying a read-only operation, but doesn't disclose behavioral traits like whether it requires specific permissions, how it handles large vaults, what format the output takes, or if it 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 with zero wasted words. It's front-loaded with the core purpose, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters with 0% schema coverage, no annotations, no output schema, and multiple sibling tools, the description is incomplete. It doesn't explain parameters, output format, or usage context, leaving significant gaps for an AI agent to understand how to invoke this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter details. The description doesn't mention any parameters (vault, total, counts, verbose) or explain their purposes, leaving all four parameters undocumented. This fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('unresolved links in vault'), making the purpose understandable. It doesn't explicitly differentiate from sibling tools like 'obsidian_links' or 'obsidian_deadends', but the specific focus on 'unresolved' links 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'obsidian_links' (which might list all links) or 'obsidian_deadends' (which might list broken links). The description lacks context about prerequisites, timing, or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool counts words and characters, implying a read-only operation, but doesn't clarify if it requires specific permissions, how it handles errors (e.g., invalid file paths), or what the output format looks like (e.g., structured data vs. raw text). For a tool with 5 parameters and no annotations, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: a single sentence that directly states the core functionality and default behavior. Every word earns its place with no redundancy or fluff, making it efficient for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, no annotations, no output schema), the description is incomplete. It lacks details on parameter usage, output format, error handling, and differentiation from siblings. While concise, it doesn't provide enough context for an agent to reliably invoke the tool without guessing at parameter meanings or behavioral outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning none of the 5 parameters have descriptions in the schema. The tool description only implies the 'file' parameter via 'active file' and hints at 'words' and 'characters' as metrics, but doesn't explain 'vault', 'path', or the boolean nature of 'words' and 'characters'. It adds minimal semantic value beyond the schema's titles, failing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Count words and characters' with the specific resource being 'active file' by default. It uses a specific verb ('Count') and identifies the resource scope. However, it doesn't explicitly differentiate from potential sibling tools like 'obsidian_file_info' that might provide similar metrics, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal usage guidance: 'default: active file' suggests it operates on the current file if no parameters are specified. However, it offers no explicit guidance on when to use this tool versus alternatives like 'obsidian_file_info' or 'obsidian_read', nor does it mention any prerequisites or exclusions. This lack of comparative context limits its helpfulness.
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. 'List saved workspaces' implies a read-only operation but doesn't specify what format the listing returns, whether it's paginated, if it requires specific permissions, or how it handles the optional parameters. The description lacks behavioral 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise at just three words, front-loading the core purpose without any unnecessary elaboration. Every word earns its place in communicating the essential function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters (0% documented in schema), no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns, how to use the parameters, or provide any behavioral context needed for proper invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for both parameters, the description provides no information about what 'vault' or 'total' parameters do. The description doesn't mention parameters at all, leaving their purpose and usage completely undocumented despite the schema showing they exist.
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 'List saved workspaces' clearly states the action (list) and resource (saved workspaces), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'obsidian_workspace_load' or 'obsidian_workspace_save' which also deal with workspaces but perform different 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 multiple workspace-related tools in the sibling list (workspace_load, workspace_save), there's no indication of when listing workspaces is appropriate versus loading or saving them.
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 saves a workspace, implying a write operation, but doesn't disclose critical traits such as whether it overwrites existing workspaces, requires specific permissions, affects other Obsidian features, or what happens on failure. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words—it directly states the tool's purpose without redundancy. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly, earning a top score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a write operation with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover parameter meanings, behavioral details, or return values, leaving significant gaps for the agent to understand how to use the tool effectively in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no descriptions for the two parameters (vault and name). The description adds no information about these parameters—it doesn't explain what 'vault' or 'name' refer to, their formats, or default behaviors. With low coverage and no compensation in the description, the score reflects inadequate parameter semantics.
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 ('Save') and resource ('current layout as workspace'), providing a specific verb+resource combination. It distinguishes this from sibling tools like obsidian_workspace_load (which loads) and obsidian_workspace (which likely lists workspaces). However, it doesn't explicitly differentiate from all siblings, such as obsidian_create or obsidian_save-like operations, which keeps it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., having an open layout), exclusions, or comparisons to siblings like obsidian_workspace_load or obsidian_workspace. This leaves the agent without context for tool selection, resulting in a low score.
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 'List' implies a read-only operation, the description doesn't specify whether this requires specific permissions, what format the output takes (e.g., file paths, metadata), whether it's paginated, or if there are any rate limits. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a simple listing tool and front-loads the core functionality immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and low schema description coverage, the description is insufficiently complete. It doesn't explain the output format, error conditions, or behavioral constraints. While the tool appears simple, the description leaves too many contextual gaps for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'in the vault' which relates to the 'vault' parameter, but with 0% schema description coverage, the parameter's purpose and optional nature aren't explained. The description adds minimal value beyond the schema, which already shows 'vault' as optional with a null default. Since schema coverage is low, the description doesn't adequately compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and target resource ('.base files in the vault'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'obsidian_files' or 'obsidian_search', but the specificity of '.base files' provides some implicit distinction. This is clear but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools like 'obsidian_files', 'obsidian_search', and 'obsidian_base_query', there's no indication of when this listing tool is preferred over those. The description only states what it does, not when it should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'List backlinks' implies a read-only operation, it doesn't specify what format the backlinks are returned in, whether there are rate limits, authentication requirements, or how errors are handled. The description provides minimal behavioral 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just 7 words, front-loading the core purpose immediately. Every word earns its place: 'List backlinks to a file' states the action, and '(default: active file)' provides important contextual information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters with 0% schema coverage, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what backlinks are in this context (Obsidian notes referencing the target file), how results are structured, or how parameters interact. For a tool with this complexity and lack of structured documentation, the description should provide more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for all 5 parameters, the description provides no information about what 'vault', 'file', 'path', 'counts', or 'total' mean or how they interact. The description mentions 'default: active file' which hints at the 'file' parameter but doesn't explain the relationship between 'file' and 'path' parameters or what 'counts' and 'total' control.
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: 'List backlinks to a file' with the verb 'List' and resource 'backlinks to a file'. It distinguishes from some siblings like 'obsidian_links' (which might list outgoing links) by focusing on incoming references. However, it doesn't explicitly differentiate from all similar tools like 'obsidian_search' which might also find references.
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 provides implied usage context by specifying 'default: active file', suggesting this tool is primarily for examining backlinks to the current file. However, it doesn't explicitly state when to use this versus alternatives like 'obsidian_search' for finding references, or mention prerequisites like needing an open file. No explicit when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a listing operation (read-only implied) and mentions default behavior for the active file, but doesn't describe what format the links are returned in, whether there's pagination, what happens with non-existent files, or any rate limits. The description provides basic behavioral context but leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise at 8 words, front-loading the core purpose ('List outgoing links from a file') and efficiently adding the default behavior in parentheses. Every word earns its place with zero redundancy or wasted space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters (0% schema coverage), no annotations, and no output schema, the description is incomplete. It doesn't explain what the parameters do, what format the output takes, or important behavioral aspects like error handling. While the purpose is clear, the description doesn't provide enough context for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 4 parameters, the description must compensate but only partially does so. It mentions 'default: active file' which relates to the 'file' parameter, but doesn't explain 'vault', 'path', or 'total' parameters. The description adds minimal value beyond what the schema provides, failing to adequately compensate for the schema coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List outgoing links from a file' with a specific verb ('List') and resource ('outgoing links from a file'). It distinguishes from sibling 'obsidian_backlinks' which would list incoming links, but doesn't explicitly differentiate from other link-related tools like 'obsidian_unresolved' or 'obsidian_deadends'.
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 provides implied usage guidance by mentioning 'default: active file', suggesting this tool is for examining link relationships from a source file. However, it doesn't explicitly state when to use this vs. alternatives like 'obsidian_backlinks' (incoming links) or 'obsidian_unresolved' (broken links), nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 performs a removal operation, implying mutation, but does not disclose behavioral traits such as permissions required, whether the removal is reversible, error handling (e.g., if the property doesn't exist), or side effects. The description is minimal and lacks critical context for a mutation tool, leaving significant gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that is front-loaded with the core action and includes a useful default note. There is no wasted language, and it effectively communicates the essential information in a compact form, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with 4 parameters, 0% schema description coverage, no annotations, and no output schema, the description is insufficiently complete. It lacks details on parameters, behavioral implications, error cases, and return values, leaving the agent with inadequate information to use the tool correctly and safely in various contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'default: active file', which hints at the 'file' parameter's behavior but does not explain the four parameters (vault, name, file, path) or their relationships. With 0% schema description coverage, the description fails to compensate by adding meaningful semantics beyond the schema, leaving parameters largely undocumented and unclear in usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and target ('a property from a file'), making the purpose specific and understandable. It distinguishes from siblings like 'obsidian_property_set' (which sets properties) and 'obsidian_property_read' (which reads properties), though it doesn't explicitly mention these alternatives. The purpose is not tautological with the name, as it elaborates on the action and context.
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 provides implied usage by specifying 'default: active file', suggesting it can be used without specifying a file. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., 'obsidian_property_set' for modification or 'obsidian_delete' for file deletion), and does not mention prerequisites or exclusions. The context is clear but incomplete for optimal agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool reads file contents, which implies a read-only operation, but doesn't clarify permissions, error handling (e.g., if the file doesn't exist), or output format (e.g., plain text, markdown). For a 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with the core purpose ('Read file contents'), followed by a brief clarification in parentheses. Every word earns its place, with no redundant or unnecessary information, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no annotations, no output schema), the description is insufficiently complete. It doesn't explain the parameters, return values, or behavioral nuances like error cases. While it states the purpose clearly, it lacks details needed for reliable tool invocation in a broader context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 parameters (vault, file, path) with 0% description coverage, and the tool description doesn't mention any parameters. This fails to compensate for the schema's lack of documentation, leaving users unclear about what these parameters do, how they interact (e.g., whether 'file' or 'path' takes precedence), or their expected formats.
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 ('Read file contents') and resource ('file'), making the purpose immediately understandable. It distinguishes itself from siblings like 'obsidian_append' or 'obsidian_create' by focusing on reading rather than modifying content. However, it doesn't explicitly differentiate from other read-related tools like 'obsidian_daily_read' or 'obsidian_property_read', which slightly limits sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by specifying the default behavior ('default: active file'), suggesting it can be used without parameters for the active file. However, it lacks explicit guidance on when to use this tool versus alternatives like 'obsidian_daily_read' for daily notes or 'obsidian_property_read' for metadata, and doesn't mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Get daily note path' but doesn't disclose behavioral traits such as whether it requires specific permissions, how it determines the path (e.g., based on current date or a parameter), what happens if no daily note exists, or if it's read-only. This leaves significant gaps for a tool that likely interacts with file systems.
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 'Get daily note path.' is a single, efficient sentence that is front-loaded and wastes no words. It directly conveys the core action without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a simple input schema, the description is incomplete. It doesn't explain what the tool returns (e.g., a file path string, an error if not found), behavioral aspects like idempotency or side effects, or how it integrates with sibling tools. For a tool in a complex Obsidian ecosystem, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter ('vault') with 0% description coverage, and the tool description doesn't mention parameters at all. However, with 0 parameters effectively (since 'vault' is optional with a default of null), the baseline is 4, as there's little need for parameter explanation. The description doesn't add meaning but doesn't need to compensate for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get daily note path' clearly states the verb ('Get') and resource ('daily note path'), making the purpose immediately understandable. It distinguishes from siblings like 'obsidian_daily_read' (which reads content) and 'obsidian_daily' (which might create or manage daily notes), but doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing a vault configured), exclusions, or related tools like 'obsidian_daily' or 'obsidian_vault' for 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. While 'List' implies a read-only operation, it does not specify whether this tool requires specific permissions, how it handles large vaults, what the output format is, or if there are rate limits. The description lacks details on behavioral traits 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 a single, efficient sentence with zero waste. It is front-loaded with the core purpose, making it easy to parse and understand quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It adequately states the purpose but fails to address parameter usage, behavioral context, or output details, leaving significant gaps for the agent to navigate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters 'vault' and 'total' are undocumented in the schema. The description does not mention these parameters at all, failing to compensate for the coverage gap. It adds no meaning beyond what the schema provides, leaving the agent uncertain about parameter usage.
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 'List files with no outgoing links' clearly states the verb ('List') and resource ('files with no outgoing links'), making the purpose specific and unambiguous. It effectively distinguishes this tool from siblings like 'obsidian_links' (which likely lists links) or 'obsidian_orphans' (which might list unlinked files), by focusing on files lacking outgoing links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 prerequisites, context, or exclusions, such as how it differs from 'obsidian_orphans' or 'obsidian_unresolved', leaving the agent to infer usage based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic function. It doesn't disclose behavioral traits like whether it's read-only (implied but not stated), performance characteristics, how it handles large vaults, what format the output takes, or any limitations. The description adds minimal context beyond the core 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, efficient sentence that immediately communicates the core function without any wasted words. It's perfectly front-loaded with the essential information and contains no redundant or unnecessary elements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 undocumented parameters, no annotations, and no output schema, the description is inadequate. It explains what the tool does at a high level but provides no guidance on how to use it effectively, what inputs it expects, what format the output takes, or any behavioral constraints. The context demands more comprehensive documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for both parameters, the description provides no information about what 'vault' or 'total' mean. It doesn't explain whether 'vault' refers to a vault name/path, what happens when null, or what 'total' controls (count vs. list). The description fails to compensate for the complete lack of parameter documentation in the 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 with a specific verb ('List') and resource ('files with no incoming links'), distinguishing it from siblings like obsidian_backlinks (which likely lists incoming links) and obsidian_deadends (which might list files with no outgoing links). It precisely defines what constitutes an 'orphan' file in the Obsidian context.
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 for identifying isolated files in a knowledge graph, but provides no explicit guidance on when to use this tool versus alternatives like obsidian_search or obsidian_files. It doesn't mention prerequisites, exclusions, or specific workflows where this tool is most appropriate.
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 MCP server](https://glama.ai/mcp/servers/Storks/obsidian-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Storks/obsidian-mcp)

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

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

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