obsidian-bridge

by dkdottk

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: v1.0.0
Disambiguation4/5
Most tools have clear distinct purposes, but the overlapping modify operations (create, append, patch) and specialized daily note variants (daily_read, daily_append) could potentially be confused by an agent without careful reading. Overall, descriptions help disambiguate.
Naming Consistency3/5
Tool names share the 'obsidian_' prefix but mix verb-only names (create, append, read), verb-object names (daily_read, daily_append), noun-verb names (tags_list, commands_list), and a noun phrase (files_by_tag). This inconsistency makes the set less predictable.
Tool Count4/5
With 15 tools, the server is well-scoped for Obsidian vault management, covering CRUD, search, tags, daily notes, commands, and UI interaction. It's slightly on the higher end but still appropriate for the breadth of functionality.
Completeness4/5
The core note lifecycle is covered (create, read, update via append/patch, delete), along with search, tags, daily notes, and command execution. Minor gaps exist such as no rename/move or folder creation, but these are not critical for most workflows.
Average 3.8/5 across 15 of 15 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 17 commits in the last 12 weeks
- Last stable release on August 7, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the basic action and does not disclose side effects such as changing the UI state, opening a new leaf, or the result if the path is invalid. The description adds little beyond the title, offering no behavioral context like error behavior or Obsidian application requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence without any redundant or filler content. Every word contributes to the core meaning, 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?
The tool has simple parameters and no output schema, but the description is too minimal. It lacks important context such as how this differs from obsidian_read, whether the note must exist, and the effect of the 'newLeaf' parameter. For a UI interaction tool, a bit more guidance would make it complete enough for an agent to use confidently.
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 already describes both parameters fully: 'path' with an example and 'newLeaf' with its meaning. The description does not add any additional semantics beyond the schema, so the baseline of 3 is appropriate given 100% 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 'Open a note in the Obsidian UI' clearly identifies the action (open) and the resource (a note), and specifies the target environment (Obsidian UI). It distinguishes this tool from siblings like obsidian_read (which reads content programmatically) and obsidian_create (which creates 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 such as obsidian_read or obsidian_daily_read. It does not mention prerequisites, whether the note must already exist, or that this is intended for UI-facing operations rather than programmatic access.
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 must disclose behavioral traits, but it only mentions 'Obsidian's simple search' without explaining its syntax, limitations, or return format. Read-only nature and result structure are not described.
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 that states the core functionality without unnecessary words. It is appropriately 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 only two parameters and no output schema, the description lacks guidance on usage context and does not describe what the search returns. This makes it incomplete 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage of parameters, each with a description. The tool description adds no extra semantic detail beyond the schema, which is acceptable given the 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 'search' and the resource 'vault', and specifies 'full-text' to distinguish it from tag-based or metadata search. This differentiates it from siblings like obsidian_files_by_tag.
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. It does not mention exclusions, prerequisites, or when a different tool 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden for behavioral disclosure. It only mentions 'via vault search', which hints at the mechanism but doesn't specify whether this is read-only, how tag matching works (exact vs partial), or what the output format is. No side effects or changes to the vault are disclosed. For a simple search operation this is acceptable but insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence: 'Find notes that contain a given tag via vault search.' It is front-loaded with the core purpose and contains no redundant words or filler. This is an ideal length and structure.
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 tool is simple (one required parameter, no nested objects, no output schema), so the description is mostly adequate. However, it does not state what the return value is (file paths? note names? note contents?) or any limits (e.g., whole vault vs current folder). Given the absence of an output schema and annotations, the description leaves reasonable questions unanswered for an agent.
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%: the parameter 'tag' is well-documented in the schema with examples (e.g., 'project or #project'). The tool description merely repeats 'given tag' without adding new semantic details. Since the schema covers everything, the description adds no extra value, so the baseline score of 3 applies.
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 function: 'Find notes that contain a given tag via vault search.' The verb 'Find' and resources 'notes' and 'tag' make the purpose specific. However, it does not explicitly distinguish itself from sibling tools like obsidian_search (full-text search) or obsidian_tags_list (list all tags), so it misses the differentiation required for a 5.
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 you know a tag and want notes with that tag. However, it provides no explicit guidance on when to prefer this over obsidian_search (which could also find tagged notes via search query) or obsidian_tags_list (to discover tags). No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 does not mention side effects, what happens if the target heading/block/frontmatter field does not exist, or whether changes are in-place and irreversible. Only the high-level action is described.
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 well-structured sentence that front-loads the primary operations and target types. Every word adds value, with no redundancy 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?
With no annotations and no output schema, the description is insufficient for a 5-parameter tool. It lacks details on target resolution, error handling, confirmation behavior, and whether it creates missing headings/fields. This is a significant gap for a mutation tool with multiple modes.
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 60%, and the description adds meaning to targetType and operation by naming heading/block/frontmatter and insert/prepend/replace. However, it does not clarify how frontmatter values are encoded, how block references are resolved, or the format of heading paths beyond what the schema provides.
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 inserts, prepends, or replaces content relative to headings, block references, or frontmatter fields. This precise verb+resource structure distinguishes it from siblings like obsidian_append and obsidian_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 by naming operations and target types, but it does not explicitly state when to choose this tool over alternatives like obsidian_append. There is no when-not-to-use guidance or mention of 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?
The description explicitly discloses the destructive behavior of replacing the entire contents, which is valuable given no annotations. However, it does not mention other behavioral aspects like directory creation, path validation, or required permissions.
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 directly conveys the tool's purpose. Every word contributes meaning, with no unnecessary filler.
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 two-parameter tool, the description covers the core action and destructive nature. However, it lacks guidance on when to choose this over sibling tools, and with no annotations, the description carries the full burden for behavioral context, which is only partially met.
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 descriptions cover 100% of the parameters, so the baseline is 3. The description adds minimal semantic value beyond the schema, only reinforcing that content replaces the entire note, which is already stated in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a note or replace its entire contents' clearly states the action (create/replace) and resource (note). It distinguishes from sibling tools like append and patch by emphasizing replacing the entire contents.
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?
There is no guidance on when to use this tool versus alternatives such as obsidian_append or obsidian_patch. The description simply states what the tool does without any exclusions or contextual triggers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains the two output modes (markdown vs JSON) based on the asJson flag, which is useful, but it does not disclose error behavior, access requirements, or the read-only nature beyond the verb 'Read'. The description is adequate but not rich.
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 with no wasted words. It front-loads the core action and then specifies the conditional behavior, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description gives the agent enough to invoke it correctly by clarifying the return format for both parameter states. It lacks details about error cases or default values, but those are not critical for basic invocation. The description is sufficiently complete given the tool's simplicity.
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 already provides 100% coverage for both parameters, including descriptions of path and asJson. The description's reference to 'asJson' reiterates the schema rather than adding new semantic meaning. It meets the baseline but does not enhance parameter understanding.
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) and the resource (a note), and differentiates itself from siblings like create, append, and delete. The mention of 'as markdown or as structured JSON metadata' adds precision beyond just 'read a note'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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_list or obsidian_search. There is no mention of scenarios where this read tool is appropriate or not, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the basic action (list files and folders) but does not disclose critical behavioral traits such as whether the listing is recursive, what the return format is, whether hidden files are included, or how errors (e.g., invalid path) are handled. This leaves significant uncertainty for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the verb 'List' and the object 'files and folders'. It is free of unnecessary words and the parenthetical adds value by clarifying the default behavior. Every word earns 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?
The tool is simple (one optional parameter, no output schema, no annotations). The description covers the essential purpose and the path parameter behavior. However, it lacks details about the return value format and whether the listing is recursive, which are important for an agent to correctly use the result. Given the low complexity, the description 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 schema coverage is 100%: the 'path' parameter is described as 'Directory path relative to vault root. Omit for root.' The description essentially repeats this ('root when path is omitted') without adding new meaning beyond the schema. Since schema already documents the parameter well, 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 tool's function: 'List files and folders at a vault directory'. The verb 'List' is specific, the resource is defined as 'files and folders', and the scope is a vault directory. It also clarifies the default behavior ('root when path is omitted'), distinguishing it from sibling tools like obsidian_read (which reads file content) and obsidian_search (which searches).
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 the tool: whenever you need to list directory contents. It does not explicitly mention alternatives or exclusions, but the purpose is self-evident and differentiated from siblings. The note about omitting path for root is a useful usage guideline. However, it stops short of stating 'use this instead of X' or listing 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?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'List available Obsidian commands' without clarifying that it is a safe read-only operation, what the return format looks like, or any side effects. This leaves critical information missing for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. It contains no wasted words and is appropriately sized for a tool with no parameters.
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 zero-parameter list command with no output schema, the description covers the essential purpose. However, it does not detail the return format (e.g., command names vs IDs) or note any limitations, though the simplicity keeps the gap small.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema description coverage is 100% vacuously. The baseline for 0 params is 4, and the description does not need to add parameter details. No additional semantics are required.
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 ('List') and resource ('Obsidian commands'), clearly distinguishing it from sibling tools like obsidian_command_execute (execution) and obsidian_list (generic listing). It states exactly what the tool does.
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 you need to see available commands) but provides no explicit when-to-use guidance or alternatives. It does not mention when to prefer this over obsidian_command_execute or other listing 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?
With no annotations, the description carries the burden of behavioral disclosure. It states the operation (list) and the output (usage counts), but does not mention any caveats like read-only nature, sorting, or limitations. It is adequate for a simple list but lacks depth.
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, well-structured sentence that is front-loaded and contains no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description sufficiently conveys the main action and result. However, it could specify the return format or any additional details, but it is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain them. The baseline of 4 applies since there are no parameters to document.
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 all tags in the vault and includes usage counts. It is specific with an action verb and resource, and it distinguishes from siblings like obsidian_files_by_tag or obsidian_list.
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?
There is no guidance on when to use this tool versus alternatives such as obsidian_files_by_tag or obsidian_search. The description only says what it does, not when it should be chosen.
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 mark destructiveHint=true, so the description doesn't need to restate danger. But the description adds only a cautionary note about explicit user request, which is more about usage. It doesn't detail what commands might do, what side effects occur, or whether the execution is reversible. Given the annotation, the bar is lower, but no additional behavioral context is provided.
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 short sentences, immediately stating the action and restriction. No filler or redundancy. 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?
The tool is simple (one parameter, no nested objects, no output schema). However, the description does not state what happens after execution (e.g., returned output, success/failure). Given destructiveHint, more cautionary context about possible side effects would strengthen completeness. It is minimally adequate but lacks return-value and consequence information.
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%, so the parameter is already fully described. The description repeats 'by id' but adds no new meaning beyond the schema's example and format. Baseline 3 is appropriate since the schema carries the semantic weight.
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 purpose is clear: 'Execute an Obsidian command by id' uses a specific verb (execute) and resource (Obsidian command) with the key parameter (id). It also stands apart from sibling tool 'obsidian_commands_list' by implying action rather than listing. The description precisely names the operation.
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?
Provides explicit guidance: 'Only use when the user explicitly asks for it.' This clearly states a usage restriction (when-not). However, it does not mention alternatives or when to prefer other tools like obsidian_commands_list to obtain command IDs, so it misses the 'alternatives' component of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses the environment variable OBSIDIAN_DAILY_NOTE_PATH and the default path, which is useful. However, it does not explain what happens if the note does not exist (e.g., error vs. empty content) or whether the note is created on read, which could be a behavioral concern. The 'read' name implies non-destructive operation, but additional context would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential information without any wasted words. It is concise and immediately understandable.
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 zero-parameter, read-only tool, the description is largely complete: it identifies the exact note (today's) and the path resolution. It could mention handling of missing files, but given the simplicity and the absence of an output schema, this is a minor gap. The sibling tool context is not necessary to disambiguate since the purpose is clear.
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 zero parameters, so there are no parameter semantics to explain. Baseline for 0 parameters is 4, and the description does not need to compensate for any schema gaps. It correctly avoids mentioning parameters since none exist.
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 today's daily note, with a specific verb ('Read') and resource ('today's daily note'). It distinguishes itself from the sibling tool 'obsidian_read' by specifying 'today's' and providing the path format.
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 reading the current daily note, but it does not explicitly mention alternatives or when not to use it. For example, it does not say to use 'obsidian_read' for other notes or past daily notes. The guidance is minimal and implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It explicitly states that it appends (not overwrites) and creates the note if missing, which are the key behavioral traits. It does not mention return values, permissions, or edge cases, but for a simple append operation, these disclosures are adequate and add value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/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 action, the target resource, and a key edge case (creates if missing). Every part earns its place, and the structure is ideal for quick scanning.
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?
The tool is very simple (single parameter, no output schema, no nested objects), and the description covers the core functionality and the main conditional behavior. Minor gaps exist, such as not mentioning timezone handling for 'today' or the return value, but these are not critical for basic usage. Overall, the description is sufficiently complete for the tool's simplicity.
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 already provides 100% description coverage for the only parameter ('content') with the same wording as the tool description ('Markdown to append to today's daily note'). The description does not add additional meaning or context beyond what the schema provides, so the 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 action ('Append markdown') and the specific resource ('today's daily note'), plus the notable behavior of creating the note if missing. This distinguishes it from sibling tools like obsidian_append, which likely targets arbitrary notes, making the purpose unambiguous.
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 by specifying 'today's daily note' and the create-if-missing behavior, implying it is the tool for append-to-daily-note tasks. However, it does not explicitly mention alternatives (e.g., obsidian_append for other notes) or include when-not-to-use language, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the tool checks reachability and authentication, but does not describe the outcome format (e.g., boolean, status object) or any potential errors/timeouts. It is adequate but lacks rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently conveys the core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no annotations), the description is mostly complete for its purpose. However, without an output schema, it would be stronger if it mentioned the type of result returned, but the core behavior is clearly communicated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. The description doesn't need to explain parameters, and the baseline for zero parameters is 4.
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 ('Check') and clearly identifies the resource ('Obsidian Local REST API') and the two conditions being verified (reachability and authentication). This clearly distinguishes it from sibling tools like obsidian_create or obsidian_read, which perform content operations.
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 clearly establishes the tool's purpose, allowing an agent to infer it should be used to verify connectivity/authentication before other operations. However, it does not explicitly state when to use it vs alternatives or mention any exclusions, so it falls short of a 5.
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?
There are no annotations, so the description bears the burden of behavioral disclosure. It explicitly states the action (append to end) and the side effect (creates if needed), which covers the core behavior. It omits details like permissions or return values, but for a simple append these are less critical.
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 with no filler, front-loading the action and including the key side effect in parentheses. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, this description is complete: it states the action, the target, the side effect, and the content type. It provides sufficient context for an AI agent to select and invoke the tool correctly among many siblings.
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%, with both 'path' and 'content' already well-described. The description adds no additional parameter semantics beyond what the schema provides, 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 uses a specific verb+resource combination: 'Append markdown to the end of a note.' It clearly states the operation and target, and distinguishes from siblings like obsidian_create or obsidian_patch by specifying the append-to-end behavior and the create-if-needed 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 conveys when to use the tool by stating the append action and its create-if-needed fallback, giving clear context for appending to notes that may not exist. Though it doesn't explicitly name alternative tools, the usage intent is clear and sufficient.
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?
The description adds meaningful behavioral context beyond the destructiveHint annotation by clarifying the nuanced safety net (trash vs permanent deletion). It also reinforces the requirement for explicit user intent before irreversible deletion, which is critical for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and front-loaded: the main purpose is stated in the first four words, and the second sentence adds crucial usage guidance without any fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool, the description fully covers the essential behavioral nuance (trash vs permanent) that an agent needs to know. The schema handles parameter details, and no output schema exists, so no further return-value explanation is required. The tool is simple, and the description is complete for its scope.
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 already covers 100% of parameters with clear descriptions (path with example, permanent with 'Requires explicit user intent'). The description mentions 'permanent=true' but does not add significant semantics beyond what the schema provides, so the baseline of 3 for high schema coverage 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 opens with 'Delete a note', which is a specific verb+resource combination that clearly distinguishes this tool from its siblings like obsidian_create or obsidian_read. It unambiguously communicates the tool's primary action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'By default moves to trash; set permanent=true only when the user explicitly asks.' This clearly states when to use the default behavior versus the permanent deletion flag, offering a when-not that helps avoid accidental data loss.
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-bridge MCP server](https://glama.ai/mcp/servers/dkdottk/obsidian-bridge/badges/card.svg)](https://glama.ai/mcp/servers/dkdottk/obsidian-bridge)

Score Badge

Copy to your README.md:

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

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/dkdottk/obsidian-bridge'

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