obsidian-mcp-complete

by jagoff

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes, but the multiple search tools (obsidian_search, obsidian_smart_search, obsidian_rag_query, etc.) and several note manipulation tools could cause confusion for an agent without careful reading of descriptions.
Naming Consistency5/5
All tools follow the consistent pattern 'obsidian_verb_noun' using snake_case, which is predictable and easy to navigate.
Tool Count3/5
66 tools is a large number, but the scope of Obsidian vault management is broad, covering notes, canvas, search, graph, batch operations, and more. However, some tools may be redundant, making the count feel somewhat heavy.
Completeness4/5
The tool set comprehensively covers CRUD for notes, canvases, tags, links, attachments, graph traversal, batch operations, and vault analysis. Minor gaps exist, such as no explicit folder creation tool.
Average 3.5/5 across 66 of 66 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, which align with the description's 'Replace' implying mutation. However, the description adds no additional behavioral context beyond what annotations provide, such as impact on note metadata or versioning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that gets to the point, but it lacks structure and details. It is front-loaded with the action but omits essential information that would warrant higher 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 no output schema and many sibling tools, the description is incomplete. It does not specify what 'active note' means, success/failure conditions, or how this relates to other similar endpoints like obsidian_patch_active.
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 one required parameter 'content' with no description. The description does not clarify what format the content should be (e.g., Markdown, plain text) or how it replaces the existing body, leaving ambiguity.
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 it replaces the body of the active note, providing a specific verb and resource. However, it does not differentiate from sibling tools like obsidian_patch_active or obsidian_post_active, which may perform similar actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as obsidian_patch_active or obsidian_post_active. There is no mention of prerequisites, context, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds minimal behavioral context, not explaining what constitutes a backlink or outgoing link, nor the impact of limit/offset for pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but it sacrifices informativeness for brevity. Given four parameters, it could include a brief explanation of modes and pagination without being verbose.
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?
The description omits essential context such as return format, pagination behavior, and precise definition of orphan notes. For a tool with no output schema and low parameter coverage, more detail is 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 description includes no information about parameters beyond what is in the schema. With schema coverage at only 25% (only 'vault' described), the description fails to compensate for the undocumented mode, limit, and offset parameters.
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 finds notes with no backlinks, no outgoing links, or neither, which precisely maps to the three mode enum values. The name 'find_orphans' and the contrast with sibling tools like 'find_broken_links' make the purpose distinct.
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 (e.g., find_broken_links, search, graph_stats). The description lacks context for selecting appropriate modes or usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the tool is read-only. The description does not add extra behavioral context (e.g., performance characteristics, scope of scanning, or error conditions). It is adequate but does not enrich the safety profile.
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 a single concise sentence that efficiently conveys the core purpose. However, it lacks structured breakdown of usage or parameters, which would improve utility without adding much length.
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 simple nature of the tool (list operation with 3 parameters, no output schema), the description should cover parameter usage and behavior (e.g., that it scans all notes). It omits these details, making it incomplete for agent 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?
Schema description coverage is low (33%). Only the 'vault' parameter has a description; 'limit' and 'offset' lack any documentation in schema or description. The tool description does not explain these parameters, leaving the agent unaware of pagination and result limiting.
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 lists broken wiki/Markdown links that don't resolve to notes. The verb 'List' and resource 'broken links' are specific, but it does not differentiate from sibling tools like obsidian_find_orphans, which addresses a related but distinct concept.
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, such as obsidian_find_orphans or obsidian_search. There is no mention of prerequisites, typical use cases, or when not 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?
Annotations indicate it is not read-only and not destructive. The description adds only 'search and replace' which is already implied by the name. It does not clarify behavior such as whether replaceAll is destructive, what happens if the search string is not found, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, which is concise, but it lacks structure and omits important details. It could be longer to include usage guidance and parameter semantics without being verbose.
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, 3 required, and no output schema, the description is too brief. It does not explain return values, edge cases, or the effect of each parameter option. The presence of annotations reduces the burden somewhat, but the description still falls short.
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 only 29%. The description adds minimal parameter meaning ('literal or regex matching and replaceAll') but does not explain key parameters like caseSensitive, vault, or the behavior when options are used. The schema itself provides descriptions only for vault and path.
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 verb 'search and replace', the resource 'inside one note', and key features 'literal or regex matching and replaceAll'. This distinguishes it from siblings like obsidian_append_to_note or obsidian_patch_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or compare to similar tools like obsidian_regex_replace.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is read-only and non-destructive. The description adds that it uses the 'search endpoint', but does not elaborate on return format, pagination, or potential side effects. With annotations covering safety, the description adds minimal 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is very concise and front-loaded with the key action. However, it may be too brief, sacrificing clarity and completeness for 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?
Given the tool runs a complex query (Dataview DQL) and has no output schema, the description should at least hint at the return format or provide examples. It is incomplete, lacking usage context, parameter details, and result expectations.
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 clarify parameters. It mentions running a query but does not explain the 'query' string format (e.g., DQL syntax) or the 'timeoutMs' parameter beyond what the schema provides. The parameter names are somewhat self-explanatory, but the description adds no extra meaning.
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 that the tool runs a Dataview DQL query, which is a specific type of query. It distinguishes this from other search tools like obsidian_search or obsidian_search_jsonlogic by specifying 'Dataview DQL', but does not explicitly differentiate from 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 no guidance on when to use this tool versus the many sibling search tools (e.g., obsidian_search, obsidian_search_paths, obsidian_query_notes). There is no hint about prerequisites or context, leaving the agent to guess.
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?
Annotations already declare readOnly and non-destructive; description adds only the TF-IDF and clustering method, with no additional behavioral context like output format or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise but lacks structure and important details; could be expanded to cover parameters and usage.
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?
No output schema, and description does not hint at return value; for a tool performing TF-IDF and clustering, more context is needed for proper 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?
Schema description coverage is 33% (only 'vault' has a description); tool description provides no parameter details, leaving limit and minFiles unexplained.
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?
Description clearly states the tool maps vault themes using TF-IDF-style term extraction and lightweight clustering, distinguishing it from sibling tools like search or graph stats.
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?
No explicit guidance on when to use vs alternatives, but the unique purpose implies thematic analysis; could be improved with direct comparisons.
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?
Annotations lack idempotent and destructive hints; description does not elaborate on behavior when overwrite is false and file exists, error handling, or side effects. Minimal behavioral disclosure beyond the basic write nature.
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?
Extremely concise single sentence with no extraneous text. However, it sacrifices useful detail that could be included without significantly lengthening the description.
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?
With 5 parameters, no output schema, and overlapping sibling tools, the description fails to clarify the canvas file format, required node/edge structure, or success/failure signals. The tool's complexity demands 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?
Schema description coverage is only 40%; the description only mentions 'nodes and edges' implicitly but adds no semantic detail for parameters like nodes, edges, or overwrite. It does not explain the expected structure of nodes/edges or the effect of overwrite=true/false.
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 creates or overwrites an Obsidian .canvas file from nodes and edges. It specifies the resource type (.canvas) and the input format, distinguishing it from other canvas-related tools like obsidian_canvas_create.
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 such as obsidian_canvas_create or obsidian_canvas_patch. The description does not address prerequisites, limitations, or common scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only, non-destructive, non-idempotent. Description adds that it appends Markdown via Local REST API, but does not discuss error conditions or behavior when no active note exists. Adequate but minimal.
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?
Description is one sentence with 11 words, no redundancy. Very concise, though it sacrifices useful detail. Good front-loading of action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 param, no output schema) and presence of annotations, the description covers basic purpose and mechanism. However, it lacks guidance on preconditions, error handling, and expected behavior for edge cases. Adequate for a simple tool but not comprehensive.
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 has 0% description coverage for the single required 'content' parameter. The description only implies content is Markdown but does not specify format, length, or constraints. Insufficient compensation for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it appends Markdown to the currently active note, distinguishing it from siblings that target specific notes or perform other operations (e.g., obsidian_append_to_note vs active, obsidian_patch_active). However, no explicit contrast with 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?
No guidance on when to use this tool versus alternatives. Does not mention prerequisites (e.g., an active note must exist) or exclusions. Usage is implied only.
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?
The description lists actions including delete, yet annotations state destructiveHint=false, creating a contradiction. No additional behavioral context (e.g., side effects, permissions) is provided beyond the action list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure. It could be improved by front-loading the purpose and separating actions or parameters.
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 (8 parameters, no output schema, many siblings), the description is incomplete. It omits details on action differences, required fields (none marked required), and return behavior, leaving 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 only 25% (2 of 8 parameters have descriptions). The description does not compensate by explaining key parameters like period, date, folder, or content, leaving the agent with insufficient guidance.
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 specifies the verbs (read, create, upsert, append) and the resource (daily, weekly, monthly, quarterly, or yearly notes), differentiating it from siblings like obsidian_daily_note and obsidian_create_note.
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 periodic notes but provides no explicit guidance on when to use this tool versus alternatives or when not to use it, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only behavior. The description adds that it requires an external CLI to be installed, which is important context. However, it does not disclose potential timeouts, response format, or other side effects beyond the prerequisite.
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?
Two concise sentences with no wasted words. Could benefit from more structured information but remains efficient.
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 11 parameters and no output schema, the description lacks detail on return values, parameter usage, and interaction with sibling tools. It feels incomplete for a complex tool.
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 only 9% schema description coverage, the description should explain key parameters like k, folder, tag, raw, multi, etc. It does not add meaning beyond the parameter names. The 'question' role is implied but not detailed.
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 it runs the obsidian-rag CLI for semantic retrieval and LLM answering, which distinguishes it from other search tools. However, it does not explicitly name sibling tools or differentiate them.
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 mentions the prerequisite (rag installed and indexed) but provides no guidance on when to use this over alternatives like obsidian_search or obsidian_smart_search. Usage is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is clear. The description adds truncation behavior via maxChars, but does not explain the effect of the 'format' parameter or error handling for missing paths. With annotations covering the safety profile, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, which is minimal and front-loaded. However, it omits important details about parameters and usage, making it less effective 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?
The tool has 4 parameters, no output schema, and many sibling tools (over 60). The description does not explain return values, error cases, or how to differentiate from similar tools like obsidian_read_note, obsidian_query_notes, or obsidian_search. This leaves significant gaps for the 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 only 25% (only 'vault' has a description). The description mentions truncation, which relates to maxChars, but does not explain the meaning of 'paths', 'format', or provide additional semantic context. With such low schema coverage, the description should compensate but fails to do so.
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 reads multiple notes and can truncate content. The verb 'read' and resource 'multiple notes' are specific, and it distinguishes from the sibling 'obsidian_read_note' which reads a single note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 such as obsidian_read_note for single reads or obsidian_batch for other batch operations. The description does not include any when-to-use or when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description adds minimal value. It confirms the read-only nature but does not disclose any behavioral traits like response format, performance characteristics, or handling of timeouts.
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 sentence that is front-loaded with the action and resource. No extraneous words or filler.
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 JSONLogic query (nested object parameter) and no output schema, the description is insufficient. It does not hint at the structure of the query or what the response looks like, leaving the agent with an incomplete understanding of the tool's 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 coverage is 0%, meaning the JSON schema does not describe the 'query' object properties. The description does not compensate by explaining what the query parameter should contain (e.g., JSONLogic format) or the purpose of timeoutMs. This leaves the agent with no guidance on parameter semantics.
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 specifies the action (run a JSONLogic query) and the resource (Obsidian Local REST API search endpoint). It distinguishes itself from siblings like obsidian_search and obsidian_search_dataview by explicitly mentioning JSONLogic.
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 obsidian_smart_search. No context is given for when JSONLogic is appropriate or what prerequisites exist.
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?
The description only mentions 'optionally creating it' but does not disclose behavior when create is false and note is missing, nor idempotency or error states. Annotations provide minimal hints but do not compensate.
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?
Single sentence, 10 words, front-loads the action. No unnecessary information.
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 and no output schema, the description is too sparse. Missing details on return value, error handling, and boundary conditions (e.g., note missing without create).
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 adds meaning for 'prepend' and 'create' parameters, but vault, path, and content are already described in the schema. With 40% schema coverage, the description partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (append or prepend Markdown) and the resource (a note), with the option to create it. It distinguishes from siblings like obsidian_create_note (overwrites) and obsidian_patch_note (patches).
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 vs alternatives such as obsidian_upsert_note or obsidian_create_note. Lack of usage context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation (readOnlyHint=false) and non-destructiveness (destructiveHint=false). The description adds that the attachment must be base64-encoded, which is a critical behavioral constraint. However, it omits other behaviors such as overwrite behavior, file naming, or size limits.
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 a single concise sentence with no filler. It is appropriately sized for its content, though it could be slightly expanded to cover key behaviors without becoming verbose.
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?
The tool has 4 parameters and no output schema, yet the description only states the broad purpose. It does not explain success indicators, error conditions, or how vault and overwrite affect behavior. This is insufficient for an agent to use the tool reliably.
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 only 50%, with no descriptions for dataBase64 and overwrite. The description mentions 'base64-encoded' but does not detail the parameter format or behavior. It fails to compensate for the missing schema descriptions, leaving the agent underinformed.
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 verb 'import' and the resource 'base64-encoded attachment into the vault,' which is distinct from sibling tools like obsidian_create_note or obsidian_list_attachments. It leaves no ambiguity about the action and target.
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, contrasting tools, or scenarios where other tools like obsidian_batch_create_notes might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, which are consistent with patching. The description adds that patching is done by heading, block, or frontmatter, but does not disclose details like whether targets are created if missing, or behavior on failure. There is no contradiction with annotations.
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 a single sentence that front-loads the core action ('Patch the active note') and enumerates key input dimensions. It is concise with no wasted words, though slightly more structure could improve 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?
The tool has 4 required parameters, no output schema, and annotations are all false. The description does not explain return values, error conditions, or prerequisites (e.g., active note must be open). It is incomplete for a mutation tool of this complexity.
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 explains targetType (heading/block/frontmatter) and operation (implied by 'Patch'), but does not define 'block reference' or clarify the meaning of each operation (append/prepend/replace). This leaves ambiguity for the agent.
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 it patches the active note, specifying three distinct target types (heading, block reference, frontmatter key). This distinguishes it from sibling tools like obsidian_patch_note which likely patches a specific note by path.
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 vs alternatives like obsidian_append_to_note or obsidian_replace_in_note. Usage is implied only by the description's mention of 'active note', but no exclusions or comparisons 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?
Annotations (destructiveHint=false) are not contradicted, but the description fails to disclose behavioral traits like in-place modification, atomicity, or error handling. With no idempotentHint, it is unclear whether repeated calls are safe. The description adds no behavioral context beyond the action itself.
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?
A single sentence that front-loads the action and key elements (what is patched, how). Every word contributes to the purpose, with no 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?
For a tool with 6 parameters, no output schema, and no behavioral hints, the description is too brief. It does not explain return values, failure modes, or constraints (e.g., only one element per call). The agent lacks critical context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 33% (only vault/path have descriptions). The description clarifies that targetType can be heading/block/frontmatter and operation can be append/prepend/replace, adding meaning beyond the enum. However, 'content' remains unexplained, and target is not elaborated. The description partially compensates for low schema coverage.
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 identifies the verb 'patch' and the target resource ('one heading, block reference, or frontmatter key'), specifying the allowed operations (append/prepend/replace). This distinguishes it from siblings like 'obsidian_append_to_note' or 'obsidian_replace_in_note' by targeting a specific element within a note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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, exclusions, or context where other tools (e.g., 'obsidian_replace_in_note') would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds that it's a 'query', confirming non-destructive intent, but does not disclose important behaviors like whether it returns full note content or just metadata, nor does it mention pagination or rate limits. Still, annotation coverage lowers the burden.
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?
A single sentence of 15 words, front-loading the core concept 'structured Dataview-like query' and listing key parameters. No redundancy or wasted words.
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?
Without an output schema, the description does not explain the return value structure (e.g., whether it returns note paths, full note bodies, or metadata). It also omits details on pagination and the meaning of 'frontmatter equality/regex'. For a tool with nested objects and 9 parameters, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 11%, so the description must compensate. It mentions 'tags, folders, linksTo, frontmatter equality/regex, sort, limit', covering most parameters but leaving out details like the format of frontmatter queries or how offset works. This is adequate but not thorough.
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 it performs a 'Structured Dataview-like query' and lists key filter criteria (tags, folders, linksTo, frontmatter). This makes the tool's purpose distinct from write operations, but it doesn't explicitly differentiate from siblings like obsidian_search_dataview or obsidian_smart_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?
No guidance is provided on when to use this tool versus alternatives (e.g., full-text search via obsidian_search). The context signals include many sibling tools, but the description offers no when-to-use or when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's mention of 'find' aligns. However, it does not add behavioral details like algorithm used or assumptions about link direction, which are partially covered by the 'direction' parameter in schema.
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 a single sentence with no wasted words. However, it could benefit from a brief expansion to cover parameter hints and usage context without becoming verbose.
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 5 parameters and siblings with overlapping functionality (e.g., obsidian_traverse_graph), the description lacks completeness. It does not explain when to use this tool, how parameters affect behavior, or what the output looks like.
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 coverage is only 40%, with descriptions for 'vault', 'from', 'to'. The description only implies 'from' and 'to' but does not explain 'maxDepth', 'direction', or 'vault'. Critical parameter context is missing.
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 verb 'find' and resource 'shortest graph path', specifying it operates between two notes. It is distinct from siblings like obsidian_traverse_graph, which is more general.
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 vs alternatives such as obsidian_traverse_graph or obsidian_graph_stats. The agent is left without context for 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?
The description adds little beyond the annotations. Annotations already indicate idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description does not disclose what happens if the task or line doesn't exist, or whether the operation is atomic. It only restates the basic function.
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 a single concise sentence that is front-loaded with the action. However, it could include a brief list of modifiable fields (checked, status, text) without becoming verbose.
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?
The description is incomplete for a tool with 6 parameters and no output schema. It does not mention the optional vault parameter or the three modifiable fields (checked, status, text). An agent cannot fully understand the tool's capabilities from the description alone.
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 coverage is 33% (only vault and path have descriptions). The description adds meaning for 'line' (1-based) but does not explain the purpose of 'checked', 'status', or 'text'. With low schema coverage, the description should compensate by describing the modifiable fields, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (update), the resource (one Markdown task), and the identification method (by note path and 1-based line number). This distinguishes it from sibling tools like obsidian_list_tasks (list) or obsidian_create_note (create).
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 updating a specific task, but it does not provide explicit guidance on when to use this tool versus alternatives (e.g., obsidian_list_tasks for viewing tasks, or other update tools). No exclusions or context for when not to use are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide idempotentHint=true, so the description adds the merging behavior of frontmatter. However, it does not disclose whether content is fully replaced or merged, nor the impact on existing metadata like tags. With moderate annotation coverage, the description adds some value but not deep 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?
Two sentences, concise and direct. Every word adds value: 'Create or replace a note' captures the action, 'Can merge supplied frontmatter with existing frontmatter' provides a key detail. No superfluous information.
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?
The tool has 5 parameters, no output schema, and many sibling tools. The description does not mention return values, success/failure indicators, side effects, or constraints like file size limits. Given the complexity, the description is incomplete and leaves the agent without sufficient context for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 60%, and the description mentions frontmatter merging, which relates to the frontmatter and mergeFrontmatter parameters. However, it does not explain the content parameter (missing schema description) or provide syntax details beyond the schema. Baseline 3 is appropriate as the description adds marginal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates or replaces a note and can merge frontmatter, which is specific. However, it does not differentiate from sibling tools like obsidian_create_note or obsidian_patch_note, missing an opportunity to clarify its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as obsidian_create_note for pure creation or obsidian_patch_note for updates. The description does not mention prerequisites, exclusions, or typical use cases, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is not read-only, not destructive, not idempotent, and not open-world. The description adds the behavior of replacing template variables but does not disclose side effects like whether it modifies the target file in place or creates a new file, nor does it explain the overwrite parameter's effect.
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?
Two sentences; the first sets the action, the second lists variables. Could be slightly more structured but remains efficient and front-loaded.
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?
No output schema is provided, and the description omits important context such as what happens if the template is missing, if the target already exists with overwrite off, or the return value. For a tool with 5 parameters and no output documentation, this is incomplete.
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 adds meaning to the 'variables' parameter by listing placeholders (date, title, vault). However, schema coverage is low (40%), and the description does not explain 'overwrite' or 'targetPath' behavior beyond the schema's reference.
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 renders a template into a target note, specifying the exact verb and resources. It distinguishes from siblings like obsidian_create_note or obsidian_patch_note by focusing on template substitution.
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 such as obsidian_create_note or obsidian_patch_active. It does not mention prerequisites or scenarios where this tool is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide minimal info (readOnlyHint false etc.). Description adds that operations are best-effort unless stopOnError is true, which is useful but doesn't detail error handling or side effects.
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?
Two sentences with no wasted words; essential info front-loaded.
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?
Complex nested input schema and no output schema; description is too brief. Lacks details on structuring operations, response format, and error behavior.
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 low (33%). Description provides no additional meaning for parameters like operations or stopOnError beyond 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 executes multiple filesystem note operations in one call, distinguishing it from single-operation siblings like obsidian_create_note or obsidian_read_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this batch tool vs individual operations. The description only mentions best-effort behavior, not conditions for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is clear. The description adds that results include usage counts and sample notes, which is useful but minimal. No contradictions or additional behavioral details beyond the annotation.
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, focused sentence with no redundant information. It is efficiently front-loaded.
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?
Despite having no output schema, the description does not clarify the return format or pagination behavior. It only vaguely mentions 'usage counts and sample notes.' The tool has 5 parameters and no output schema, so more detail is needed for complete 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?
Schema description coverage is only 20% (only vault is described). The tool description does not explain the meaning of nameRegex, sampleLimit, limit, or offset. 'Usage counts and sample notes' hints at sampleLimit but not explicitly. The description 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all tags across the vault with usage counts and sample notes' clearly states the action (list), resource (tags), and additional output details (usage counts, sample notes). It distinguishes from sibling tools like obsidian_list_tasks or obsidian_manage_tags.
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 given on when to use this tool versus alternatives such as obsidian_manage_tags or obsidian_search. The description does not specify prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses skipping certain directories and the option to remove (dryRun implied), but lacks details on side effects, reversibility, or security implications. Annotations are minimal and don't add much context beyond the description.
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 concise sentence that front-loads the action and key behaviors. Every word earns its place, with no 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 the complexity (4 parameters, no output schema, minimal annotations), the description is incomplete. It does not explain the return value, the effect of 'limit', or the behavior when dryRun is true. Significant gaps remain.
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 coverage is only 25% (one parameter described). The description adds minimal meaning: it hints at dryRun via 'optionally remove' but does not explain 'folder', 'limit', or their defaults. This is insufficient for effective use.
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 finds and optionally removes empty directories bottom-up, with specific exclusions. It is distinct from sibling tools like obsidian_delete_folder or obsidian_delete_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It only implicitly suggests use for cleaning empty directories, but no when-not conditions or sibling comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, covering safety. The description adds that no note bodies are read, which is useful behavioral context. However, it does not disclose potential case sensitivity, regex support, or result format, leaving some ambiguity.
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?
A single, front-loaded sentence that contains only essential information. Every word contributes to understanding, with no redundancy or unnecessary 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?
For a tool with 4 parameters (1 required) and no output schema, the description lacks crucial details about query syntax, extension filtering, and return structure. It is insufficient for an agent to use the tool without additional inference.
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 only 25% (only 'vault' described). The description does not elaborate on parameters like 'query' or 'extension', which are critical for using the tool correctly. With low schema coverage, the description should compensate but fails to do so.
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 'Search filenames and vault-relative paths without reading full note bodies' clearly states the verb (search), resource (filenames and paths), and a key differentiator (not reading bodies), distinguishing it from sibling tools like obsidian_search which likely search content.
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 when only path/filename information is needed, but lacks explicit when-to-use or when-not-to-use guidance. Among siblings, there are related tools like obsidian_list_files and obsidian_search; no comparison or exclusion criteria 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?
Annotations already indicate readOnlyHint=true, so the description's non-destructive nature adds no new behavioral insight. It does not disclose what the output represents (paths, nodes, edges) or how traversal handles loops or missing notes.
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?
A single sentence that is front-loaded with the action and includes all critical inputs (start, depth, direction). No wasted words; highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and moderate parameter count, the description lacks details on return format (e.g., list of note paths, nested structure). It also does not explain the vault parameter or limits. Adequate for basic usage but incomplete for complex scenarios.
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 covers three of five parameters indirectly: start as 'starting note', depth as 'N hops', direction as 'forward, backward, or both'. However, vault and limit are not mentioned, and schema coverage is only 40%, so the description partially compensates but misses key parameters.
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 specifies it walks the note graph from a starting note for N hops in forward, backward, or both directions. This differentiates it from siblings like obsidian_vault_graph which cover the whole vault, and other note-reading tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., obsidian_vault_graph for full vault graph, obsidian_get_backlinks for direct links). No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the key behavioral detail that the tool performs a dry-run by default, which is not captured by annotations. However, it does not disclose that actual rewrites modify note files, the potential impact on broken links, or the operation's reversibility. Annotations (all false) provide minimal safety hints, so the description partially compensates but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two brief clauses—and front-loads the primary action. Every word serves a purpose, and there is no redundancy. It could include more detail without becoming verbose, but given its length, it is efficient.
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?
The description omits important contextual details: it does not specify the scope of link rewriting (entire vault vs. specific notes), mention error handling or constraints, or describe the return value (e.g., count of updated links). Given the absence of an output schema, this lack of completeness hampers an agent's ability to infer proper usage and expected outcomes.
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 adds value by clarifying the dryRun parameter's default behavior ('Dry-run by default'), which the schema leaves undocumented. However, it redundantly restates the from/to parameters without additional nuance, and vault is omitted. With 50% schema coverage, the description partially compensates but does not fully explain all parameters.
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 verb 'rewrite' and the resource 'incoming wiki-links and Markdown links', specifying the action of changing link targets from one path to another. This distinguishes it from sibling tools like obsidian_links (listing links) or obsidian_find_broken_links (finding broken links), making its purpose unmistakable.
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, nor does it mention prerequisites, scope, or typical use cases. The only contextual hint is the default dry-run behavior, which implies a safety check but does not offer explicit when-to-use or when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description adds no new behavioral insights. It correctly implies no destruction but does not describe performance implications of the limit parameter or the impact of includeUnresolved. Score is adequate but lacks extra 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?
A single, front-loaded sentence with no waste. Every word adds value, and the structure is optimal for quick parsing.
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?
The description is too terse given three parameters and no output schema. It does not clarify the return format (e.g., what 'adjacency lists' means), the effect of the limit parameter, or how includeUnresolved affects the graph.
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 low (33%), and the overall description does not explain any of the three parameters. The agent must infer meaning from parameter names alone. This is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Export'), the resource ('vault link graph'), and the output format ('nodes, edges, and adjacency lists'). It distinguishes well from sibling tools like obsidian_graph_stats (statistics) and obsidian_traverse_graph (traversal).
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 such as obsidian_graph_stats or obsidian_traverse_graph. No explicit 'when to use' or 'when not to use' instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true) already confirm safe, read-only behavior. The description adds the scope of returned data but does not disclose any additional behaviors (e.g., caching, performance). With annotations covering safety, the description contributes some context but not extensive 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 one concise sentence, front-loaded with the verb 'Return' and all key output categories. No unnecessary words, efficient for an agent to process.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description lists five output types but does not elaborate on 'vault totals' or 'graph health'. For a stats tool, this may be sufficient for basic understanding, but lacks detail for precise invocation. The two parameters are minimally explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (vault described, top not). The description implies 'top' relates to 'top folders' but does not explicitly explain that it controls the number of top folders returned. It partially adds meaning beyond the schema but leaves ambiguity for the agent.
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 explicitly lists the five output categories (vault totals, file extensions, top folders, word-count sample, graph health), providing a clear purpose. It distinguishes from sibling 'obsidian_graph_stats' which focuses only on graph stats. However, 'vault totals' is somewhat vague.
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 given on when to use this tool versus siblings like obsidian_graph_stats, obsidian_search, or obsidian_list_files. The description does not indicate scenarios or prerequisites, so the agent lacks decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=false, destructiveHint=false. The description adds 'automatic graph layout' but does not explain overwrite behavior or side effects. It would benefit from mentioning that overwrite=true may destroy existing content. No contradiction with annotations.
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 a single sentence, highly concise with no wasted words. It front-loads the action and purpose. Could be improved with slight structuring but overall efficient.
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 (6 parameters, nested arrays, no output schema), the description is too brief. It does not explain node/edge ID uniqueness, the effect of direction, or the overwrite flag. The return value (created canvas file) is not described. Significant gaps remain.
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 low (33%). The description adds meaning that nodes/edges are semantic and layout is automatic, but it fails to explain key parameters like direction, overwrite, or the node/edge structure details. The majority of parameters are undocumented in the description.
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 'Create an Obsidian JSON Canvas from semantic nodes/edges with automatic graph layout.' It specifies the verb (create), resource (Obsidian JSON Canvas), and key differentiating features (nodes/edges, auto-layout), distinguishing it from siblings like obsidian_canvas_patch and obsidian_canvas_read.
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 lacks explicit guidance on when to use this tool versus alternatives like obsidian_canvas_patch or writing canvas files manually. The usage is implied by the name and purpose but not clearly stated, missing 'when not to use' or 'alternative tools'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (readOnlyHint=false, destructiveHint=false). Description adds creation behavior but omits details like overwrite semantics, error handling, or constraints. Adequate but not comprehensive.
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?
Single sentence with clear verb and key features, front-loaded and without unnecessary words.
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 6 parameters, nested objects, no output schema, and many sibling tools, the description is too brief. Lacks information on return values, error handling, and detailed behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%. Description mentions frontmatter and wiki-links but does not elaborate on vault, content, or overwrite parameters beyond schema. Baseline 3 due to partial coverage.
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?
Clearly states 'Create a new Markdown note' with optional frontmatter and wiki-links, distinguishing it from sibling tools like append or 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?
No guidance on when to use this tool versus alternatives like obsidian_append_to_note or obsidian_update_note. Does not mention conditions or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds 'return a structured line diff', which is consistent but does not elaborate on behavioral traits like handling of large files or limits. The transparency is adequate but minimal.
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 sentence that directly states what the tool does with no unnecessary words. It is appropriately front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description only mentions 'structured line diff' without specifying the structure. Parameters like context and maxLines affect output but are not explained. For a comparison tool, more completeness about output and parameters would be helpful.
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 low (33%), and the description does not explain the meaning of parameters like rightPath, rightText, context, or maxLines. The description implies two comparison modes but no details, failing to add value beyond the sparse 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 compares two notes or a note with supplied text and returns a structured line diff. The verb 'compare' and resource 'notes' are specific, and the tool is unique among siblings, which include no other diffing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as querying notes individually. No when-not or explicit context for usage 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?
The annotations already declare readOnlyHint=true and destructiveHint=false. The description adds 'through Local REST API' but does not disclose what happens when no note is active (e.g., error or null response) or the required Obsidian setup. Limited value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words, front-loaded with key information. Efficient for a zero-parameter tool.
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 output schema, the description should hint at return format (e.g., note content, metadata). It doesn't. Also missing error cases or setup requirements. Minimal completeness for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so no burden on description. Baseline 4 applies as schema coverage is 100% (trivially). Description adds nothing, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read'), the resource ('note currently active'), and the mechanism ('through Local REST API'). It distinguishes itself from sibling tools like obsidian_read_note by specifying the active note rather than a path.
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 (e.g., obsidian_read_note for a specific note). No mention of prerequisites or conditions (e.g., Obsidian must be running with the REST API plugin active).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description's simple 'Read' statement adds little extra behavioral context. It does not contradict annotations, but provides no new insights beyond what annotations convey.
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 a single sentence that immediately conveys the tool's purpose. It is front-loaded and efficient, though slightly more detail could be added without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has a simple read operation with well-documented schema and annotations, the description is minimally adequate. However, it lacks details like behavior when no frontmatter exists or prerequisites, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both parameters (vault, path) are documented in the schema. The description adds no further meaning or context for the parameters beyond what is already specified.
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 reads YAML frontmatter from a note. It uses specific verbs and resource, distinguishing it from siblings like obsidian_read_note (full content) and obsidian_update_frontmatter (write).
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 that it should be used for metadata-only access or when to prefer over read_note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the sorting behavior (newest first) but does not mention default extension (.md) or pagination behavior, leaving 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb 'List' and the core purpose, making it concise and easy to parse, though it omits important details.
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 5 parameters and no output schema, the description is insufficient; it does not explain filtering, pagination, or the return format, leaving the agent without crucial context for correct 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 only 20% schema description coverage, the description should compensate by explaining key parameters like folder, extension, limit, and offset, but it does not mention any of them beyond the implicit listing behavior.
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 it lists recently modified notes or files sorted newest first, which is specific and distinguishes it from other listing/search tools like obsidian_list_files or 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (to see recent modifications), but does not explicitly state when not to use it or mention alternatives among the many 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?
Annotations provide basic safety flags (readOnlyHint false, destructiveHint false, etc.) but the description adds no additional behavioral context beyond stating that an API key is required. It does not explain the potential consequences of the request (e.g., that it can modify data) or any rate limits or error 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 (two sentences) and front-loaded with the core purpose. Every sentence adds value: the first identifies the tool as an escape hatch, the second notes the required API key.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is an 'escape hatch' for arbitrary HTTP requests, the description is minimally complete. However, it omits details about the base URL, response format, or possible error states. Since there is no output schema, the agent could benefit from knowing what to expect.
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 5 parameters with 0% coverage in description or schema descriptions. The description provides no explanation of how to use parameters like 'body', 'contentType', or 'timeoutMs'. The method and path are somewhat self-explanatory, but the lack of guidance on body format or content type is a gap.
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 identifies this as an 'escape hatch' for making arbitrary REST API requests to Obsidian. The phrase 'escape hatch' immediately signals that it is a general-purpose tool, distinct from the many specific sibling operations (e.g., obsidian_create_note, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly states that this tool is for making custom REST API requests that are not covered by other tools, but it does not explicitly state when to use or not use it, nor does it name any specific alternatives. The requirement of OBSIDIAN_API_KEY is mentioned but without context on prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds the nuance of 'optional' bridge, which is useful but does not disclose behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no filler. Every word adds value, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status check with no output schema, the description could hint at the return format or common states. While adequate, it leaves the agent guessing about the response structure.
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?
No parameters in schema (coverage 100%), so baseline is 4. The description need not add parameter details, and it correctly omits them.
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 (check) and resource (Obsidian Local REST API bridge status). It is specific but does not differentiate from the sibling 'obsidian_status', leaving ambiguity about which status tool to use.
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_status'. Missing context about prerequisites or typical scenarios, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds behavioral traits beyond annotations: BM25 ranking, boosting for specific elements, and compact snippets. Annotations already indicate read-only and non-destructive. No contradiction.
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?
Single sentence, 10 words, no wasted text. Could be slightly more expansive to aid understanding, but overall concise.
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?
Lacks explanation of return format, snippet behavior, and boosting details. No output schema exists, so description should fill gaps but does not. Incomplete for a smart search tool.
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 only 20% (vault). Description provides no additional meaning for parameters like query, contextChars, limit, offset. It fails to compensate for low schema coverage.
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?
Description clearly states it performs BM25-ranked vault search with boosting for title/tag/heading and compact snippets. This distinguishes it from sibling search tools like obsidian_search or obsidian_rag_query.
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 vs. alternatives. Does not mention when not to use or compare to other search tools available on the server.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=false. The description aligns with these, confirming mutation and idempotency. It adds no additional behavioral context beyond the annotations, which is adequate.
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?
A single, efficient sentence that conveys the core functionality without any redundant or extraneous information.
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 params, enum, nested objects, no output schema), the description is too minimal. It does not explain how actions interact (e.g., delete requires keys, merge vs replace semantics) or indicate the outcome/return value.
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?
Input schema provides descriptions for parameters like 'action', 'values', 'keys' with 60% coverage. The description does not add extra meaning beyond what the schema offers, so a baseline score of 3 is appropriate.
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 verb ('Set, merge, replace, or delete') and resource ('frontmatter keys in a note'). It distinguishes from sibling tools like obsidian_patch_note or obsidian_get_frontmatter by focusing specifically on frontmatter manipulation.
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 (e.g., obsidian_patch_note, obsidian_upsert_note). The description lists actions but does not explain the appropriate context for each (merge vs replace vs delete).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, consistent with the mutation implied by 're-layout'. However, the description does not disclose whether existing node properties are preserved, or that dryRun defaults to true (schema shows default). This leaves ambiguity about default 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 two sentences long, front-loading the purpose and then clarifying the dry-run behavior. Every sentence adds value 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 no output schema and the complexity of layout manipulation, the description lacks detail on what exactly 're-layout' entails (e.g., does it fully reposition nodes? preserve edges? return new canvas or void?). This leaves significant gaps for correct 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 schema description coverage at 50%, only vault and path have documentation; direction and dryRun lack schema descriptions. The description adds no extra parameter info beyond implicitly mentioning dry-run, failing to compensate for the gap.
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 re-layouts a JSON Canvas using dagre, distinguishing it from other canvas tools like obsidian_canvas_patch or obsidian_canvas_create. The verb 're-layout' and resource 'JSON Canvas' are specific, and the dry-run feature adds clarity.
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 the tool is for automatic layout with dagre but does not explicitly state when to use it over alternatives like manual patching or creation. It lacks exclusion criteria or when-not scenarios, leaving the agent without clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds no further behavioral details beyond stating it 'suggests' actions, which aligns but does not disclose traits like how suggestions are generated or any performance implications.
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 redundant information, making it highly concise and front-loaded.
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?
Despite being a read-only tool, the lack of output schema and the low schema coverage mean the description should offer more context about what the suggestions look like or how they are structured. It also does not explain the role of 'staleDays' even though it is a key parameter. The description is too sparse for an agent to understand the tool's full output and behavior.
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 only 33% schema description coverage, the description should compensate by explaining parameter meaning, but it does not mention any parameters (staleDays, maxSuggestions, vault). The schema provides minimal help, leaving the agent without sufficient guidance on how to use the parameters.
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 'Suggest vault reorganization actions: MOCs, consolidation, archive candidates, and missing tags' uses a specific verb ('suggest') and identifies clear resources (MOCs, consolidation, etc.), differentiating it from sibling tools like obsidian_find_orphans or obsidian_list_tags.
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 vault reorganization but does not explicitly provide when-to-use or when-not-to-use guidance, nor does it mention alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false (no readOnly, destructive, idempotent, openWorld hints), so the description carries the transparency burden. It discloses the tool modifies the canvas (add/update/remove) and optionally relayouts, but does not explain how updates work (by matching id), that relayout defaults to true, or whether operations are additive or overwrite. It provides moderate but incomplete behavioral context beyond the high-level 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 sentence that immediately states the tool's purpose and key operations. It is concise with no wasted words, front-loading the most important information (verb, resource, modifiers). Every part of the sentence earns its place.
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?
The tool has 9 parameters, no output schema, and moderate complexity with arrays. The description is extremely brief (one sentence) and omits critical details such as return value (no output schema), default values (relayout defaults to true), required fields in nested objects (addNodes requires label), and matching logic for updates. For a tool of this complexity, the description is insufficient to fully understand usage without inspecting the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema_description_coverage is 22% (only vault and path have descriptions). The description compensates slightly by grouping parameters into semantic actions (addNodes, addEdges, updateNodes, removeNodes, removeEdges, relayout, direction). However, it does not explain that addNodes requires 'label', updateNodes uses 'match', or that relayout defaults to true. Without the schema descriptions being comprehensive, the description should provide more detail to bridge the gap; it does so only partially.
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 uses a specific verb 'Patch' and clearly states the resource 'canvas'. It enumerates the operations: adding, updating, removing semantic nodes and edges, and mentions optional relayout. This distinguishes it from sibling tools like obsidian_canvas_create (create new), obsidian_canvas_read (read-only), and obsidian_canvas_relayout (only relayout), providing clarity on its combined modification+relayout purpose.
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 does not explicitly state when to use this tool over alternatives. It only implies usage for modifying existing canvases (via required path) but lacks directives like 'Use this for modifications; for new canvases use obsidian_canvas_create'. There is no guidance on when not to use it or mention of prerequisites, so the usage guidance is implicit at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds modest value by specifying the return format (line numbers, raw link targets). However, it does not disclose limits, performance characteristics, or whether backlinks from all file types are included.
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?
Single sentence of 13 words, front-loaded with the core action. No unnecessary words; every part conveys essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with no output schema, the description is mostly complete: it explains what the tool does and what the output contains. Minor gap: it does not explicitly state that the tool only returns notes that have at least one backlink, but this is implied.
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?
Input schema provides 100% coverage with clear descriptions for 'vault' and 'path'. The description adds no additional semantic information beyond the schema, so baseline 3 applies.
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 verb ('List') and resource ('notes that link to a target note'), and specifies output details ('with line numbers and raw link targets'). This differentiates it from sibling tools like obsidian_links (which lists outgoing links) or obsidian_find_broken_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?
No guidance on when to use this tool versus alternatives (e.g., obsidian_search, obsidian_links). No mention of prerequisites or exclusions. The agent must infer use cases from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with annotations (readOnlyHint=true) and adds that the tool lists tasks with filters. However, it does not disclose behavior like pagination (limit/offset) or that only tasks from markdown files are considered, beyond what is implicit. With annotations already covering safety, the description adds modest value.
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 sentence with no redundancy. Every word is necessary to convey the tool's core function. It is optimally concise.
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?
Despite having 8 parameters and no output schema, the description does not explain the return format (e.g., which task fields are returned) or how to handle pagination. Given the tool's complexity and the lack of output schema, the description is insufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is very low (13%), so the description must compensate. It maps user-facing filters ('status, tags, folder, and due dates') to parameters (checked, tag, pathPrefix, dueBefore/After), providing meaning that the schema lacks. It omits vault, limit, and offset, but these are less critical for filtering intent.
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 verb 'List', the resource 'Markdown tasks', and the scope 'across the vault'. It also mentions specific filter dimensions, distinguishing it from sibling tools like obsidian_query_notes which are more general.
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 such as obsidian_query_notes or obsidian_search for task-related queries. The description lacks usage context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false but description adds that dry-run is default, which is helpful. However, it does not disclose behavior on overwrite conflicts or whether changes are reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description does not explain return values or error behavior for batch operations. Sufficient for basic use but lacking for complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (20%). Description adds context for moves and link updates but fails to explain vault, overwrite, and dryRun beyond their defaults.
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 'Batch move/rename notes with optional incoming link updates', which distinguishes it from single-move tools like obsidian_move_note and update links tools.
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 batch renaming but does not explicitly state when to use versus alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description doesn't need to restate that. It adds context about returned data (node/edge counts, raw arrays) and the effect of includeRaw. However, no additional side effects or limitations are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences effectively convey what the tool does and how to control output detail. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the read-only nature and low parameter count, the description is reasonably complete. However, it does not describe the exact output structure or any edge cases (e.g., canvas not found), which could be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers vault and path with descriptions, but includeRaw lacks schema description. The description clarifies that setting includeRaw to true returns the full JSON, which adds value beyond 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 uses the verb 'read' and specifies the resource as 'Obsidian JSON Canvas'. It clearly distinguishes this from sibling canvas tools (create, patch, relayout) by being a read operation. The mention of 'compact semantic graph' further clarifies the purpose.
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 over other canvas tools or alternative read tools like obsidian_read_note. The description does not explain the trade-offs or context of use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark destructiveHint=true, but the description adds important context that the command must be explicitly enabled in configuration. This provides value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Front-loads the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive operation with confirmation, the description covers the key aspects: what it does, the requirement for enabling the command, and implicit safety (confirmation). No output schema exists, but the return value is not critical for a delete action.
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 single parameter 'confirmation' has a const value 'DELETE' and is required. The description does not explain its purpose or that it is a safety measure, and schema coverage is 0%.
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 states the tool deletes the active note via Local REST API, which is specific and distinguishes it from other delete tools like obsidian_delete_note. It also notes that the command must be explicitly enabled.
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 such as obsidian_delete_note or obsidian_delete_folder. The description does not mention use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds that it supports recursive walks, depth limits, and extension filtering, but fails to mention pagination (limit/offset) or the includeDirectories option. This leaves some behavioral traits undisclosed for a tool with 8 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, front-loaded sentence with no wasted words. It efficiently conveys the core purpose and key features.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no output schema, the description is incomplete. It doesn't explain the return format, pagination, or the behavior of includeDirectories. While it covers the main features, important context for a complete understanding is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 13% (only 'vault' has a description). The description adds meaning for recursive, maxDepth, and extension by mentioning them, but does not explain folder path format, limit, offset, or includeDirectories. It partially compensates but leaves gaps.
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 it lists files and folders in a vault folder, specifying key features like recursive walks, max depth, and extension filtering. This distinguishes it from other sibling tools like obsidian_list_attachments or obsidian_search paths.
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?
Implied usage: use when you need to list files/folders. No explicit when-not-to-use or alternatives mentioned. The description lacks guidance on when to prefer this over other list-like tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is not read-only and not destructive, but the description does not elaborate on side effects beyond link rewriting. Missing details on behaviors like overwrite (deletion of destination) or permission requirements. Given minimal annotations, the description adds some value but 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?
A single sentence of 14 words succinctly conveys the core purpose and key option. No wasted words; front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the essential purpose and link rewriting detail, but lacks explanation of overwrite behavior, path validation, or return values. For a tool with 5 parameters and no output schema, this is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description clarifies the updateLinks parameter by stating 'Optionally rewrites incoming wiki-links and Markdown links,' but does not add meaning to other parameters like overwrite or vault. With schema coverage at 40%, the description partially compensates but remains limited.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (move or rename) and the resource (note), and includes the optional link rewriting feature, which distinguishes it from sibling tools like obsidian_create_note or obsidian_delete_note.
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 mentions optional link rewriting but does not provide explicit guidance on when to use this tool versus alternatives like obsidian_batch_rename or when not to use it. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description adds no further behavioral context. It accurately reflects the safe read-only nature but lacks details like error handling or indexing 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?
A single sentence of 12 words is extremely concise and front-loaded, conveying the essential purpose without unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal; it does not explain the return format, how results are ordered, or how parameters like extension filter files. Given no output schema, more detail on the output would be beneficial.
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 only 25%, and the description provides no additional information about parameters like vault, folder, extension, or limit. This fails to compensate for the low coverage.
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 lists non-Markdown files, providing examples (images, PDFs, audio) and differentiating it from siblings like obsidian_list_files which likely lists all files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for non-Markdown assets but does not explicitly provide context on when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are neutral (readOnlyHint false, destructiveHint false). The description adds behavioral context: dry-run previews by default, implying actual replacement occurs only when dryRun is false. This is valuable beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information (regex/literal, vault-wide, dry-run). No extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing return value format (list of changes? count?). Does not specify whether it applies to all files or specific pathPrefix. With no output schema, the description should clarify output structure.
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 only 10% (only 'vault' described). The description does not explain parameters like caseSensitive, wholeWord, flexibleWhitespace, pathPrefix, or limit. It fails to compensate for low schema coverage.
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 function: 'Regex or literal find-and-replace across the vault' with a key feature 'dry-run previews by default'. It distinguishes from sibling tools like obsidian_replace_in_note by specifying vault-wide scope.
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 vault-wide usage but does not explicitly state when to use this tool vs alternatives like obsidian_replace_in_note (per-note). No when-not or exclusion guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and non-destructive. The description adds that results are 'ranked snippets' and supports filtering, providing behavioral context beyond annotations. No contradiction.
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 concise sentence that front-loads the core action and key features. Every word adds value.
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?
With 10 parameters and no output schema, the description is too brief. It does not explain ranked snippets behavior, pagination (limit/offset), or parameter interactions like regex flag.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (10%). The description adds meaning for query (text/regex), tag, and folder filters, but does not cover parameters like caseSensitive, includeContent, contextChars, etc. Partially compensates.
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 searches notes by text or regex, returns ranked snippets, and supports tag and folder filters. This differentiates it from sibling search tools like obsidian_search_dataview or obsidian_search_paths.
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 text/regex search with filters, but does not explicitly contrast with other search tools or specify when to use this over alternatives like smart_search or dataview.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=false. The description adds the opt-in requirement, but does not elaborate on the potential for modifications or side effects. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a short condition clause. Every word is necessary and no redundant information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of annotations (destructiveHint, readOnlyHint) and a single parameter, the description covers the essential behavioral context. However, the lack of output schema and any mention of return value or error handling leaves a minor gap. Still adequate for a simple tool.
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 one parameter 'commandId' with 0% description coverage. The description mentions 'by id' but does not clarify what constitutes a valid commandId or where to find it (e.g., from obsidian_list_commands). The agent receives minimal guidance beyond the parameter name.
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 executes an Obsidian command-palette command by its id, distinguishing it from other tools like obsidian_list_commands. The verb 'Execute' and resource 'command-palette command' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a key usage condition: 'Opt-in with OBSIDIAN_ENABLE_COMMANDS=1.' It does not explicitly state when to use versus alternatives, but the purpose is distinct enough to imply usage. Could be improved by noting cautious use given destructiveHint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description's 'list' is consistent. No additional behavioral details are provided beyond the annotations, but none are needed for this simple read-only 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?
Single sentence, no wasted words. Clearly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema), the description is complete enough. It covers what the tool does without missing essential information.
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?
No parameters exist, and schema coverage is 100%. With zero parameters, the description does not need to add parameter information, so baseline 4 is appropriate.
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 it lists Obsidian command-palette commands, with a specific verb and resource. This distinguishes it from siblings like obsidian_list_files or obsidian_list_tags.
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_execute_command or others. The description implies usage but does not provide explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true (safe read). The description adds value by specifying the four possible return types (content, full, document-map, section), which is not in the annotations. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence efficiently conveys the tool's capability. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with 6 parameters and no output schema, the description is minimal. It does not explain that the 'section' format requires the sectionType and section parameters, or that includeLinks applies only to certain formats. More detail would help the agent use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (most parameter descriptions come from schema fields). The description does not elaborate on how to use parameters like sectionType, section, or includeLinks. However, the mention of 'one section' hints at the section format, providing some context beyond 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?
Description clearly states the verb 'Read' and resource 'a note', and lists the four possible output formats: raw content, full structured content, document map, or section. This distinguishes it from write or modification siblings like obsidian_patch_note or obsidian_delete_note.
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?
No explicit guidance on when to use this tool versus alternatives like obsidian_read_many or obsidian_search. The purpose is implied by the name and description, but no exclusions or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are minimal (all false), and the description adds value by disclosing the independent reporting feature and the stopOnError flag, which are behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no wasted words, front-loading the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and minimal annotations, the description is brief but covers key behaviors. However, it lacks information about return format, prerequisites, and the maxItems limit from the schema.
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 33% (only vault described). The description adds no additional meaning to the parameters notes and stopOnError, which are critical for correct 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 clearly states 'Create many notes in one call', using a specific verb and resource, and distinguishes it from single-note creation tools like obsidian_create_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains error handling behavior ('Each item reports success or error independently unless stopOnError is true'), but does not explicitly state when to use batch vs single creation or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=false and destructiveHint=false, so the description confirms it can perform both read and write operations. However, it does not disclose behaviors like what happens when reading a non-existent note or how append behaves if the note is missing. The description adds some context but not deep behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently communicates the tool's purpose and key differentiator. Every word is necessary and front-loaded with actions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, multiple actions, no output schema), the description covers the essential purpose and key configurable aspect (date folder/pattern). It lacks details on conflict resolution or frontmatter merging, but the core functionality is well communicated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (29%). The description adds meaning for 'folder' and 'pattern' by mentioning 'configurable date folder/pattern', but does not explain 'date', 'content', or others. It partially compensates for the low coverage.
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 actions (Read, create, upsert, append) and the resource (daily note). It specifies 'configurable date folder/pattern', which distinguishes this tool from generic note manipulation siblings like obsidian_create_note or obsidian_append_to_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for daily notes with date-based organization, but does not explicitly state when to use it over alternatives or when not to use it. It provides clear context but lacks exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, but the description adds useful behavioral context: the need for an environment variable, the two deletion modes, and confirmation requirement. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no filler. Every word is necessary for understanding the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers key decision factors: action, modes, prerequisites. Lacks details on return values, but no output schema exists, so this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (2 of 4 parameters described). The description adds meaning to 'permanent' by referencing permanent deletion, but 'confirmation' and 'vault' are not further explained.
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 that the tool moves a note to trash or permanently deletes it. It distinguishes from sibling tools like obsidian_delete_folder by focusing on single note deletion.
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 mentions prerequisites (OBSIDIAN_ENABLE_DELETE=1 and confirmation) but does not explicitly guide when to use move vs permanent delete or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and non-destructive, which is consistent. The description adds behavioral detail about the specific stats returned, going beyond annotations. It does not mention performance or output format, but given annotations cover safety, this is acceptable.
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?
Single sentence with no filler. Front-loaded with the action and resource, then lists outputs. Every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple stats tool with good annotations and two parameters, the description covers key outputs. However, without an output schema, more detail on return format would improve completeness, but it's not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema describes 'vault' fully but leaves 'top' undescribed (50% coverage). The description mentions 'top connected notes', adding meaning to the top parameter. This compensates for the schema gap.
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?
Description clearly states the verb 'Return' and resource 'graph-level stats', listing specific outputs (node/edge counts, top connected notes, orphans, broken links). It differentiates from sibling tools like obsidian_vault_stats and obsidian_find_broken_links by aggregating multiple stats.
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 (e.g., obsidian_vault_stats, obsidian_find_orphans). The description only states what it does without usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context that this tool is a combined retrieval of multiple data types, which is beyond the annotations. No contradictions.
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 sentence of 10 words, front-loading the purpose. Every word is essential with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description lists the types of data returned, which is sufficient for understanding the tool's scope. It could optionally mention the format, but it is reasonably complete for a simple read tool.
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?
Input schema coverage is 100%, and both parameters are well-described in the schema. The description adds no additional parameter semantics beyond the schema. Baseline 3 is appropriate.
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 verb 'return' and specifies the exact resources: outgoing links, backlinks, tags, and frontmatter for one note. This differentiates it from sibling tools like obsidian_get_backlinks or obsidian_get_frontmatter, which are more specific.
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 use when wanting all link-related data for a single note, but does not explicitly state when to use this tool versus the more granular sibling tools. No exclusion criteria or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description doesn't need to disclose safety. However, it adds no extra behavioral context (e.g., what 'configured' means or how vaults are listed). Adequate for a straightforward read-only 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?
Four words, no fluff, front-loaded with the purpose. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only tool with clear annotations, the description provides enough context. Could mention return format, but it's sufficient for the task.
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 no parameters, so schema coverage is 100%. Description adds no parameter info, but none is needed. Baseline 4 applies.
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 verb 'list' and the resource 'configured Obsidian vaults', distinctly identifying the tool's purpose among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The usage is implied by the tool's simple listing nature, but alternatives like vault_stats or vault_suggest are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide basic hints (readOnlyHint=false, etc.). The description adds the execution requirement (env var) but doesn't detail side effects (e.g., changing active note). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, very concise, front-loads the action. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and sparse annotations, the description covers essential context: what it does, how (URI), and a critical prerequisite. Missing details on return behavior or errors, but acceptable for a one-way action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (vault and path described, execute not). The description adds no additional parameter explanations beyond schema. It does not clarify the 'execute' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Open a note in the Obsidian UI') and the mechanism ('via obsidian:// URI'). It distinguishes from siblings like obsidian_read_note or obsidian_create_note by specifying UI opening.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite (OBSIDIAN_ENABLE_UI_OPEN=1) but does not explicitly state when to use this tool versus alternatives. It implies UI opening use case, which is sufficient for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds that it 'does not execute OS commands', which is a crucial behavioral trait beyond what annotations provide, aligning with the readOnlyHint.
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 two succinct sentences with no wasted words. It is front-loaded with the action immediately, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool that builds a URI, the description is adequate. It does not explain the return value, but given the tool's purpose, it is likely clear. No output schema is provided, but the context is sufficient for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for both parameters (vault and path). The description adds no additional meaning beyond what the schema already provides, so baseline score of 3 applies.
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 states 'Build an obsidian://open URI for a note', which clearly identifies the action (build) and resource (URI for a note). It explicitly distinguishes itself from actual opening of the URI, differentiating it from sibling tools like 'obsidian_open_in_ui'.
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 notes that it 'does not execute OS commands', implying it should be used when only the URI is needed, but it does not explicitly state when to use this tool versus alternatives (e.g., when to use obsidian_open_in_ui instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value over annotations by specifying that only frontmatter tags are affected and inline tags are preserved. Annotations (idempotentHint=true, destructiveHint=false) already indicate safe, repeatable operations. The description does not contradict annotations and provides useful behavioral context, though it could detail side effects like overwriting existing tags.
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 sentence that conveys the core functionality and key constraint (inline tags preserved). It is efficiently front-loaded and contains no filler, earning the highest score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema, annotations present), the description is fairly complete. It states the scope (one note, frontmatter tags) and the preservation of inline tags. However, it could mention prerequisites like the existence of frontmatter or YAML format, and it does not describe return values (e.g., what list returns). Still, it is adequate for most use cases.
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 input schema has 50% description coverage (vault and path described, action and tags only typed). The description lists the four actions matching the enum, which helps, but it does not clarify when the tags parameter is required (e.g., for add/remove/replace but not list). The description partially compensates but leaves gaps, warranting a score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to list, add, remove, or replace frontmatter tags on a single note. It explicitly mentions that inline tags are preserved, distinguishing it from sibling tools like obsidian_list_tags (which lists all tags) and obsidian_update_frontmatter (which modifies all frontmatter). This provides a specific verb-resource combination with clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for manipulating frontmatter tags only, not inline tags. However, it lacks explicit guidance on when to use this tool versus alternatives such as obsidian_update_frontmatter or obsidian_get_frontmatter. The context is clear but does not provide exclusions or when-not scenarios, earning a score of 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, safe behavior. The description adds specific details on the content of the response (configuration, vault roots, etc.), enhancing transparency beyond annotations without contradiction.
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?
Single sentence, no wasted words, and the key information is front-loaded. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description lists what is returned. It is sufficient for a status tool, though it lacks format details. Slightly incomplete but acceptable.
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?
No parameters exist, and schema coverage is 100%. The description does not need to explain parameters, but it also does not add any parameter-related info. Baseline 4 is appropriate.
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 returns server configuration, vault roots, write safety flags, and tool capability summary. It is a distinct status/info tool among many note-manipulation siblings.
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?
No explicit guidance on when to use this tool over alternatives. The purpose is clear but the description does not specify when it should or should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond destructiveHint annotation, description details dry-run default and confirmation requirement. It also explains alternative of moving to .trash/mcp, adding valuable 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?
Two concise sentences front-load the primary action, with no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and description doesn't cover return values, vault defaults, or the exact interplay between parameters. Adequate for basic understanding but leaves gaps for a 5-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 20%, and description adds meaning only for dryRun and confirmation, not explaining permanent parameter or interactive flow. Adequate but not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete or move to trash) and resource (folder), distinguishing it from siblings like obsidian_delete_note which targets single notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions dry-run by default and confirmation requirement, guiding safe usage. It doesn't explicitly state when not to use, but context is clear.
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/jagoff/obsidian-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jagoff/obsidian-mcp)

Score Badge

Copy to your README.md:

[![obsidian-mcp MCP server](https://glama.ai/mcp/servers/jagoff/obsidian-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jagoff/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/jagoff/obsidian-mcp'

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