obsidian-ts-mcp

by dickiedyce

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 distinct purposes, but there is some overlap between 'append_to_note' and 'prepend_to_note' (both modify note content), and 'daily_append' and 'append_to_note' (both append content, but to different targets). Descriptions help clarify these differences, but an agent might occasionally confuse them when deciding between appending to a specific note versus the daily note.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case, such as 'append_to_note', 'create_note', and 'get_backlinks'. There are no deviations in naming conventions, making the set predictable and easy to parse.
Tool Count5/5
With 16 tools, the server is well-scoped for managing an Obsidian vault, covering operations like note creation, reading, updating, searching, and task management. Each tool serves a specific function without redundancy, fitting the domain's complexity appropriately.
Completeness5/5
The tool set provides comprehensive coverage for Obsidian vault management, including CRUD operations for notes (create, read, update via append/prepend), property handling, search, backlinks, tags, tasks, and vault info. There are no obvious gaps; agents can perform full workflows from note creation to organization and retrieval.
Average 3.5/5 across 16 of 16 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the action 'Set' and supported types, but lacks details on permissions, whether it overwrites existing properties, error handling, or response format. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and includes essential details about supported types. There is no wasted verbiage, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits like side effects, error conditions, or return values, which are crucial for an agent to use it correctly in context with sibling tools.
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 listing supported types (text, list, number, etc.), which clarifies the 'type' parameter beyond the schema's enum. However, with 100% schema description coverage, the schema already documents all parameters well, so the description provides only marginal additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'frontmatter property on a note', specifying what the tool does. It distinguishes from siblings like 'read_property' or 'append_to_note' by focusing on setting rather than reading or appending, though it doesn't explicitly mention these distinctions.
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 'append_to_note' or 'create_note', nor does it mention prerequisites such as needing an existing note. It only lists supported types without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves heading structure but does not cover aspects like permissions required, rate limits, error handling, or output format details (e.g., tree vs. markdown implications). For a tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly. Every word earns its place, exemplifying ideal 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 the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It covers the core purpose but lacks details on output behavior, error cases, or integration with sibling tools. Without an output schema, it should ideally hint at return values, but it does not, leaving room for improvement.
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 100%, so the schema already documents all three parameters ('file', 'path', 'format') with descriptions and an enum for 'format'. The description adds no additional meaning beyond the schema, such as clarifying parameter interactions or default behaviors. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 as 'Get the heading structure/outline of a note,' which specifies the verb ('Get') and resource ('heading structure/outline of a note'). It distinguishes from siblings like 'read_note' (full content) and 'get_tags' (metadata), though not explicitly. However, it lacks explicit sibling differentiation, preventing a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention scenarios like needing only headings versus full content (vs. 'read_note') or how it relates to other tools like 'get_backlinks' or 'list_files'. Without any usage context or exclusions, it falls short of even implied guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions filtering capabilities but fails to describe critical behaviors: it doesn't specify the return format (e.g., list structure, pagination), potential rate limits, authentication requirements, or whether it's a read-only operation (though implied by 'list'). For a tool with 7 parameters and no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('List tasks from notes') and briefly mentions key features. There's no wasted verbiage, and it's appropriately sized for the tool's complexity. However, it could be slightly more structured by separating filtering options for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (7 parameters, no output schema, no annotations), the description is incomplete. It lacks details on output format, behavioral traits like safety or performance, and doesn't fully compensate for the absence of annotations. While the schema covers parameters well, the overall context for an AI agent to use this tool effectively is insufficient.
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 100%, so the schema already documents all 7 parameters thoroughly. The description adds minimal value by hinting at filtering ('by file, completion status, or show tasks from the daily note'), which loosely maps to parameters like 'file', 'done', 'todo', and 'daily', but doesn't provide additional syntax, constraints, or interactions beyond the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List tasks from notes') and the resource ('tasks'), making the purpose immediately understandable. It distinguishes from some siblings like 'toggle_task' or 'create_note' by focusing on listing rather than modifying. However, it doesn't explicitly differentiate from 'search_vault' which might also retrieve tasks, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage by mentioning filtering options ('by file, completion status, or show tasks from the daily note'), which suggests when to use specific parameters. However, it lacks explicit guidance on when to choose this tool over alternatives like 'search_vault' or 'list_files', and doesn't mention prerequisites or exclusions, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it's a read operation, implying safety, but doesn't disclose behavioral traits like error handling, permissions needed, or what happens if the property doesn't exist. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero waste. It's front-loaded and appropriately sized for the tool's purpose, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimal but covers the basic purpose. However, it lacks details on behavior, usage context, and output, making it incomplete for effective agent use without additional inference.
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 100%, so the schema already documents all three parameters. The description adds no additional meaning beyond implying the tool reads from frontmatter, but it doesn't explain parameter interactions or provide context beyond the schema. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('read') and resource ('a frontmatter property value from a note'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'read_note' or 'get_tags', which might also involve reading from notes, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'read_note' or 'set_property'. It lacks context on prerequisites, exclusions, or comparisons to sibling tools, leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'Supports optional content and templates,' which adds some context beyond the schema, but fails to cover critical aspects like permissions needed, whether creation is idempotent, error handling for duplicate names without overwrite, or rate limits. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences that are front-loaded: the first states the core purpose, and the second provides usage context. There's no wasted verbiage, and each sentence adds value. However, it could be slightly more structured by explicitly listing key parameters or behaviors.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with 4 parameters), no annotations, and no output schema, the description is moderately complete. It covers the basic purpose and some usage but misses behavioral details like what happens on success/failure or return values. For a creation tool, more context on outcomes and constraints 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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by mentioning 'Supports optional content and templates,' which loosely relates to 'content' and 'template' parameters but doesn't provide additional syntax or format details. With high schema coverage, the baseline is 3, and the description doesn't significantly enhance understanding.
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 ('Create a new note') and resource ('in the Obsidian vault'), making the purpose immediately understandable. It distinguishes from siblings like 'append_to_note' or 'read_note' by specifying creation rather than modification or reading. However, it doesn't explicitly contrast with 'daily_note' which might also create notes, so it's not fully differentiated from all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context with 'Use this when you need to record a new session, decision, or piece of documentation,' which implies scenarios for creation. However, it lacks explicit guidance on when to use alternatives like 'daily_note' for date-based notes or 'append_to_note' for adding to existing notes. No exclusions or prerequisites are mentioned, leaving gaps in decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states what data is returned but lacks behavioral details like whether this is a fast read operation, if it requires specific permissions, or if it might fail if the vault is inaccessible. The description is minimal and does not disclose operational traits beyond the output content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the purpose and enumerates the returned data. There is no wasted text, and it directly communicates the tool's function without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter, no output schema, no annotations), the description is adequate but has gaps. It specifies what data is returned but does not cover behavioral aspects or usage context. For a simple read tool, it meets minimum viability but lacks completeness for optimal agent guidance.
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 100% description coverage, with the parameter 'info' documented as returning only a specific piece of info. The description does not add meaning beyond the schema, as it lists all possible info values but does not explain their semantics or usage. Baseline 3 is appropriate since the schema handles parameter documentation.
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 'Get' and the resource 'information about the Obsidian vault', specifying the exact data returned (name, path, file count, folder count, and size). It distinguishes itself from sibling tools like list_files (which lists files) or get_tags (which retrieves tags) by focusing on vault metadata.
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, such as requiring an open vault, or compare it to similar tools like get_outline or search_vault for different information needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions filtering capabilities but fails to describe key behaviors such as whether the list is paginated, sorted, or includes hidden files, what permissions are required, or the format of the returned data. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('List files in the vault') and immediately adds qualifying details about filtering. Every word earns its place with no redundancy or fluff, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose and filtering options but lacks details on behavioral traits like output format, pagination, or error handling. Without annotations or an output schema, users must infer these aspects, leaving room for uncertainty in tool 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 100%, with all three parameters ('folder', 'ext', 'total') clearly documented in the input schema. The description adds marginal value by mentioning filtering by folder and extension, aligning with the schema, but doesn't provide additional context like syntax examples or interaction effects between parameters. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 ('files in the vault'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'search_vault' by focusing on listing with optional filtering rather than full-text search. However, it doesn't explicitly differentiate from 'get_vault_info' which might also provide file information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the mention of filtering capabilities ('Can filter by folder and/or file extension'), suggesting this tool is for retrieving files with optional scoping. However, it doesn't explicitly state when to use this versus alternatives like 'search_vault' for content-based queries or 'get_vault_info' for metadata, leaving some ambiguity about tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that content is added 'after the frontmatter' and that the note must be 'existing', which are useful behavioral details. However, it doesn't disclose critical aspects like whether this operation is destructive (modifies the file), what happens if the file doesn't exist, or any permission/error handling, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste. The first sentence states the core functionality, and the second provides a practical use case, making it front-loaded and 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 that this is a mutation tool with no annotations and no output schema, the description is somewhat incomplete. It covers the basic purpose and a use case but lacks details on behavior, error conditions, or output. However, the 100% schema coverage for parameters and clear purpose keep it from being severely inadequate.
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 100%, so the input schema already documents all three parameters well. The description doesn't add any meaningful parameter semantics beyond what the schema provides (e.g., it doesn't clarify the relationship between 'file' and 'path' or provide examples for 'content'). Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('prepend content after the frontmatter') and resource ('a note'), making the purpose understandable. However, it doesn't explicitly distinguish this tool from its sibling 'append_to_note', which handles similar content addition but at a different location in the 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 provides some implied usage context ('useful for adding a summary or status update at the top of an existing document'), suggesting when this tool might be appropriate. However, it doesn't explicitly state when to use this versus alternatives like 'append_to_note' or 'create_note', nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context beyond the basic action by stating 'creates the daily note if it doesn't exist,' which clarifies a key behavioral trait. However, it lacks details on permissions, error handling, or response format, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with two concise sentences that directly state the purpose and a helpful usage example. Every sentence earns its place without redundancy or unnecessary elaboration, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (a mutation with creation fallback), no annotations, and no output schema, the description is minimally adequate. It covers the core action and a behavioral nuance but lacks details on return values, error cases, or integration with sibling tools, leaving room for improvement in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the input schema already documents the single 'content' parameter with its type and formatting note. The description doesn't add any parameter-specific information beyond what's in the schema, resulting in a baseline score of 3 as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'append' and resource 'today's daily note' with the specific action of adding content. It distinguishes from siblings like 'append_to_note' by specifying 'today's daily note' as the target, though it doesn't explicitly contrast with other daily-related tools like 'daily_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 provides implied usage context with 'useful for logging tasks, session summaries, or quick entries,' suggesting when to use this tool. However, it doesn't explicitly state when to choose this over alternatives like 'append_to_note' or 'create_note,' nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('toggle a task's completion status'), which implies a mutation, but doesn't disclose critical traits like whether this requires specific permissions, if the change is reversible, what happens on error, or the response format. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste: the first states the purpose, and the second explains parameter usage. It's front-loaded with the core action and efficiently conveys necessary information without redundancy or 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?
Given the tool's moderate complexity (a mutation with three parameters), no annotations, and no output schema, the description is partially complete. It covers the purpose and parameter identification well, but lacks details on behavioral traits (e.g., permissions, error handling) and return values, which are important for a mutation tool. It's adequate but has clear gaps in context.
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 100%, so the schema already documents all three parameters (ref, file, line) with clear descriptions. The description adds value by explaining the identification logic ('by ref or by file and line together'), which clarifies the parameter relationships, but doesn't provide additional syntax or format details beyond what the schema offers. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('toggle a task's completion status') and the resource ('task'), distinguishing it from siblings like 'list_tasks' (which lists tasks) or 'append_to_note' (which modifies note content). It uses precise verbs and specifies the exact operation on the target resource.
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 by specifying how to identify tasks ('by ref or by file and line together'), but it doesn't explicitly state when to use this tool versus alternatives like 'list_tasks' for viewing tasks or 'set_property' for other modifications. It provides some contextual guidance but lacks explicit when/when-not directives or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the tool is for appending to existing notes, implying mutation, but does not disclose behavioral traits such as required permissions, whether the operation is idempotent, error handling, or how it interacts with note formatting. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with two concise sentences that each add value: the first states the purpose, and the second provides usage context. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with 3 parameters), no annotations, and no output schema, the description is incomplete. It covers purpose and usage but lacks details on behavior, error cases, or output format, which are needed for adequate agent understanding.
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 100%, so the schema already documents all parameters. The description adds no additional meaning beyond what the schema provides, such as explaining the relationship between 'file' and 'path' or providing examples. Baseline 3 is appropriate when the schema does the heavy lifting.
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 content') and target resource ('to the end of an existing note'), distinguishing it from siblings like 'create_note', 'prepend_to_note', and 'read_note'. It specifies the verb+resource+scope precisely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Useful for adding session logs, tasks, or follow-up notes to an existing document'), but does not explicitly state when not to use it or name alternatives like 'prepend_to_note' or 'create_note' for new notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that it 'Always returns all tags with counts included', indicating completeness and output format, but lacks details on permissions, rate limits, or error handling. It adds some behavioral context but is 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?
The description is two concise sentences with zero waste, front-loading the core purpose ('List all tags...') and adding a behavioral note ('Always returns...'). Every sentence earns its place by providing essential information efficiently.
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 annotations, no output schema, and a simple single-parameter tool, the description is adequate but has gaps. It explains what the tool does and output behavior, but lacks details on return format, error cases, or integration with sibling tools, making it minimally viable.
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 100%, so the schema fully documents the 'sort' parameter with its enum and default. The description adds no parameter-specific information beyond what the schema provides, meeting the baseline for high 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 verb ('List') and resource ('all tags in the vault'), specifying the output includes 'occurrence counts'. It distinguishes from siblings like 'list_files' or 'search_vault' by focusing specifically on tags with counts.
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 retrieving tags with counts, but provides no explicit guidance on when to use this tool versus alternatives like 'search_vault' or 'get_vault_info'. It mentions 'Always returns all tags', which suggests it's comprehensive, but lacks context on exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the return type ('matching files and context') and search syntax, but lacks details on behavioral traits like pagination, error handling, performance limits, or authentication needs. For a search tool with no annotations, this leaves significant gaps in understanding how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by essential details in a second sentence. Every word earns its place—no fluff or redundancy—making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters with full schema coverage but no output schema and no annotations, the description is adequate for basic use but incomplete. It explains what the tool does and the query syntax, but lacks details on output structure, error cases, or advanced behavioral context, which are important for a search operation.
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 100%, so the schema already documents all parameters thoroughly. The description adds minimal value by reiterating 'Obsidian's full search syntax' for the query, but doesn't provide additional semantics beyond what's in the schema. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 resource ('the vault for text'), specifies what it returns ('matching files and context'), and distinguishes it from siblings like list_files (which lists without searching) and read_note (which reads specific files). The mention of 'Obsidian's full search syntax' further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Search the vault for text') and implies alternatives by specifying 'Obsidian's full search syntax,' suggesting it's for complex queries. However, it doesn't explicitly state when not to use it (e.g., vs. list_files for simple listing) or name specific sibling alternatives, keeping it from a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return type ('markdown content including frontmatter') and parameter requirements, but lacks details on error handling, permissions, or performance aspects like rate limits. This is adequate but has gaps for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by a concise usage instruction. Both sentences are essential—none are redundant—making it efficiently structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (simple read operation), no annotations, no output schema, and high schema coverage, the description is mostly complete. It covers purpose, return type, and parameter guidance, but could improve by mentioning error cases or output structure more explicitly.
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 100%, so the schema already documents both parameters fully. The description adds minimal value by reiterating the need for at least one parameter, but does not provide additional syntax or format details beyond what the schema specifies, aligning with the baseline for high 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 verb ('Read') and resource ('full contents of a note'), specifying it returns 'markdown content including frontmatter'. It distinguishes from siblings like 'append_to_note' or 'create_note' by focusing solely on reading without modification.
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?
It provides explicit usage context by stating 'Provide at least one of 'file' or 'path' to identify the note', which guides parameter selection. However, it does not specify when to use this tool over alternatives like 'read_property' or 'search_vault', leaving some ambiguity in sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behavior: it gets the path and creates the note if missing. However, it lacks details on permissions, file format, location, or error handling, which are important for a tool that modifies the filesystem.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded and concise with two sentences: the first states the core action, and the second specifies the return value. Every sentence earns its place without waste, making it easy to understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a tool that potentially creates files, the description is minimally complete. It covers the basic purpose and return value but omits details like output format, error cases, or side effects, which could aid the agent in safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema coverage, the baseline is 4. The description adds no parameter information, but this is acceptable as there are no parameters to document, and it clarifies the tool's action without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('get' and 'creating') and resource ('today's daily note path'). It distinguishes from siblings like 'create_note' (general creation) and 'read_note' (reading existing notes) by focusing on the daily note with creation fallback.
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 when to use it: for accessing today's daily note, ensuring it exists. However, it doesn't explicitly state when not to use it or name alternatives like 'read_note' for existing notes or 'create_note' for non-daily notes, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It clearly describes the read-only nature of listing backlinks, but doesn't mention potential limitations like whether it returns all backlinks or is paginated, what happens if no backlinks exist, or if there are rate limits. It provides basic operational context but lacks deeper 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 perfectly concise with two sentences that each serve distinct purposes: the first states the tool's purpose, the second provides critical usage guidance. Every word earns its place with zero redundancy or unnecessary elaboration.
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 read-only tool with 2 parameters and 100% schema coverage but no output schema, the description provides adequate context about what the tool does and how to use it. However, it doesn't describe the return format (e.g., list structure, what fields are included in each backlink entry), which would be helpful given the lack of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents both parameters well. The description adds valuable semantic context by explaining the relationship between 'file' and 'path' parameters ('at least one of'), which clarifies their optional but mutually reinforcing nature. This goes beyond the schema's individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List all notes that link to a given note') and identifies the resource ('backlinks/incoming links'). It distinguishes this from siblings like 'get_outline' or 'search_vault' by focusing specifically on reverse link relationships rather than content structure or general search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool ('to find backlinks for a note') and specifies the required input condition ('Provide at least one of 'file' or 'path''). However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the sibling tools for similar link-related queries.
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-TS-MCP MCP server](https://glama.ai/mcp/servers/dickiedyce/Obsidian-TS-MCP/badges/card.svg)](https://glama.ai/mcp/servers/dickiedyce/Obsidian-TS-MCP)

Score Badge

Copy to your README.md:

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

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