Obsidian Local REST API MCP Server

by j-shelfwood

Overview Schema Related Servers Score Discussions

JavaScript

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 distinct purposes, but there is some overlap between get_note/read_file and create_or_update_note/write_file that could cause confusion. The descriptions help clarify differences (e.g., get_note is legacy, write_file handles append/prepend modes), but an agent might still misselect between these pairs in certain scenarios.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case throughout (e.g., create_or_update_note, list_directory, search_vault). There are no deviations in naming conventions, making the set predictable and easy to parse.
Tool Count5/5
With 13 tools, this server is well-scoped for managing an Obsidian vault, covering operations like CRUD for notes/files, metadata handling, search, and directory listing. Each tool earns its place without feeling excessive or insufficient for the domain.
Completeness4/5
The tool set provides comprehensive coverage for vault management, including create, read, update, delete, search, and metadata operations. A minor gap exists in note linking or backlink management beyond find_related_notes, but core workflows are well-supported with no dead ends.
Average 3.2/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 94 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Delete' implies a destructive mutation, the description lacks details on permissions required, whether deletion is permanent or reversible, error handling (e.g., if path doesn't exist), or side effects. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that efficiently conveys the core action without unnecessary words. It is front-loaded with the key verb and resource, making it easy to parse and ideal for quick comprehension by an AI agent.
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 destructive nature, lack of annotations, and absence of an output schema, the description is insufficiently complete. It does not cover critical aspects like return values, error conditions, or behavioral nuances (e.g., recursive deletion for directories), leaving significant gaps for safe and effective 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?
The schema description coverage is 100%, with the single parameter 'path' clearly documented in the schema. The description does not add any semantic details beyond what the schema provides (e.g., path format examples or constraints), so it meets the baseline for high schema coverage without enhancing parameter 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 ('Delete') and the target ('a file or directory from the vault'), making the purpose immediately understandable. However, it does not differentiate this tool from potential siblings like 'write_file' or 'create_or_update_note' in terms of destructive nature, which would require explicit mention for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., item existence), exclusions (e.g., cannot delete non-empty directories if applicable), or suggest alternatives like 'write_file' for modifications, leaving the agent without contextual usage cues.
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 what the tool does but lacks details on permissions, rate limits, or output format (e.g., whether values are returned as a list, sorted, or deduplicated). 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, efficient sentence with no wasted words. It is front-loaded and clearly conveys the core functionality without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain the return values (e.g., format, structure) or behavioral aspects like error handling, making it inadequate for a tool that retrieves data without structured output documentation.
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 the parameter 'key' fully documented in the schema. The description adds minimal value by mentioning 'frontmatter key' but doesn't provide additional context like examples or constraints beyond what the schema already states.
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 ('Get') and resource ('unique values for a specific frontmatter key'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_metadata_keys' or 'search_vault', which might also involve metadata operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't clarify if this is for retrieving all values across notes or in a specific context, or how it differs from 'get_metadata_keys' or 'search_vault' for metadata-related queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves content and metadata, but lacks details on permissions, error handling (e.g., if the note doesn't exist), rate limits, or output format. The 'legacy' qualifier hints at potential deprecation but is vague, leaving critical behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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. The 'legacy' qualifier adds context without unnecessary verbosity. However, it could be slightly more structured by explicitly separating functionality from caveats.
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 lack of annotations and output schema, the description is incomplete for a retrieval tool. It doesn't explain what 'metadata' includes, the return format, or error conditions. With 1 parameter and 100% schema coverage, the basics are covered, but behavioral and output details are missing, making it inadequate for full 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?
The input schema has 100% description coverage, with the 'path' parameter clearly documented. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Baseline 3 is appropriate since the schema adequately covers the single parameter.
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 ('Get') and resource ('a specific note'), specifying it retrieves both content and metadata. It distinguishes from siblings like 'list_notes' or 'get_recent_notes' by focusing on a single note. However, the 'legacy' qualifier is vague and doesn't fully differentiate from alternatives like 'read_file'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The description implies it's for retrieving a single note, but it doesn't clarify prerequisites (e.g., note must exist), exclusions, or comparisons to siblings like 'read_file' or 'get_daily_note'. The 'legacy' hint is insufficient as actionable 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?
No annotations are provided, so the description carries full burden. It states ordering behavior ('ordered by modification time') but lacks critical details: whether it's read-only, requires permissions, includes pagination, returns metadata, or handles errors. For a retrieval tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with core functionality ('Get recently modified notes'), followed by ordering detail. Zero wasted words, efficiently conveying the essential action and key behavioral trait.
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 retrieval tool with no annotations and no output schema, the description is incomplete. It lacks information on return format (e.g., note content vs. metadata), error handling, authentication needs, or rate limits. Given the server context with multiple note-related tools, more guidance is needed to distinguish usage.
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 the single parameter 'limit' fully documented in the schema. The description adds no parameter-specific information beyond implying 'recently modified' scope, which doesn't clarify syntax or format. Baseline 3 is appropriate as the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('recently modified notes'), specifying ordering by modification time. It distinguishes from siblings like 'get_note' (single note) and 'list_notes' (unfiltered list), but doesn't explicitly contrast with 'find_related_notes' or 'search_vault' which might also return notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'list_notes', 'search_vault', or 'find_related_notes'. The description implies recency-based retrieval but doesn't specify scenarios where this is preferred over other listing/search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions 'advanced filtering', it doesn't describe what the search returns (full documents, snippets, metadata only), pagination behavior, performance characteristics, or authentication requirements. This is inadequate for a search tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that clearly states the core functionality. Every word earns its place, with no redundant information or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what the search returns, how results are formatted, whether there are limits, or how it differs from other search/list tools on the server. The 'advanced filtering' mention is too vague to be helpful.
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 thoroughly. The description adds minimal value beyond what's in the schema - it mentions 'advanced filtering' which aligns with the scope and path_filter parameters, but doesn't provide additional syntax or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as searching vault content across files, filenames, and metadata with advanced filtering. It specifies the verb 'search' and resource 'vault content', but doesn't explicitly differentiate from sibling tools like 'find_related_notes' or 'list_notes' which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'find_related_notes', 'list_notes', or 'list_directory'. It mentions 'advanced filtering' but doesn't specify what makes this tool distinct from other search/list tools in the server.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses behavioral traits like modes (overwrite, append, prepend) and handling create/update operations, but lacks critical details: permissions required, error handling (e.g., if file doesn't exist), side effects (e.g., data loss in overwrite), or response format. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: two sentences that efficiently convey core functionality without waste. Every sentence earns its place by stating the action and key features (modes, create/update).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with modes), lack of annotations, and no output schema, the description is incomplete. It should explain more about behavioral aspects like safety warnings (e.g., overwrite destroys data), prerequisites, or return values. The current text leaves gaps that could hinder correct agent usage.
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 (path, content, mode with enum and default). The description adds minimal value by mentioning modes and default behavior, but does not explain parameter interactions or provide examples. Baseline 3 is appropriate as the schema handles most semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Write file content with different modes: overwrite (default), append, or prepend. Handles both create and update operations.' It specifies the verb ('write'), resource ('file content'), and scope (create/update operations with modes). However, it does not explicitly distinguish from sibling tools like 'create_or_update_note' or 'read_file', which could cause confusion in a file system context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions modes but does not specify scenarios for overwrite, append, or prepend, nor does it reference sibling tools like 'read_file' for reading or 'delete_item' for removal. Without context, an agent might misuse it in place of other file operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action is to 'read' content, implying a read-only operation, but doesn't address potential behavioral aspects such as file format handling, error conditions (e.g., if the file doesn't exist), or performance considerations like size limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It is front-loaded with the core action and resource, 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 low complexity (one parameter, no output schema, no annotations), the description is minimally adequate. However, it lacks details on return values (e.g., content format) and doesn't leverage the absence of annotations to clarify behavioral traits, leaving gaps for a read 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?
The input schema has 100% description coverage, with the 'path' parameter clearly documented. The description adds no additional semantic context beyond what the schema provides, such as examples of valid paths or vault-specific conventions, so it 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 ('Read content') and resource ('specific file from the vault'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_note' or 'list_directory', which might also involve reading files or content from the vault.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'read_file' over similar siblings like 'get_note' or 'search_vault', nor does it specify any prerequisites or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the relationship criteria but doesn't describe output format, pagination, error handling, or performance characteristics. For a 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 a single, efficient sentence that front-loads the core purpose. Every word earns its place with no redundancy or fluff, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., list of note paths, metadata), error cases, or limitations. For a tool with 2 parameters and no structured output, more context is needed to be fully helpful.
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 ('path' and 'on'). The description adds context by mentioning 'backlinks' as a criterion, which isn't in the enum (only 'tags' and 'links'), but this is contradictory rather than helpful. Baseline 3 is appropriate as the schema does most of the work.
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 ('find') and resource ('notes related to a given note'), specifying the relationship criteria ('shared tags, links, or backlinks'). It distinguishes from siblings like 'search_vault' or 'list_notes' by focusing on relationships, though it doesn't explicitly name alternatives. This is specific but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 find notes based on relationships (tags, links, backlinks), but it doesn't provide explicit guidance on when to use this versus alternatives like 'search_vault' or 'list_notes'. No exclusions or prerequisites are mentioned, leaving usage context somewhat vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't disclose behavioral traits such as whether it requires specific permissions, how it handles large datasets, or what the output format looks like (e.g., list, JSON). This leaves gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's front-loaded and appropriately sized for a simple tool with no parameters.
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 simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on usage context, behavioral traits, and output format, which could help an agent use it more effectively in a vault with multiple metadata-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, but it could slightly enhance clarity by mentioning any implicit assumptions (e.g., scope of notes). Baseline is 4 for zero parameters.
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 ('Get') and the resource ('all available frontmatter keys from notes'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_metadata_values' or 'get_note', which might retrieve different metadata aspects, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_metadata_values' and 'get_note' that might handle related metadata operations, there's no indication of context, prerequisites, or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but lacks behavioral details. It mentions 'list all notes' and 'optional search filter', but doesn't disclose pagination, rate limits, permissions, or what 'legacy' entails (e.g., deprecated features). This leaves gaps for a read operation tool.
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. However, the parenthetical 'legacy with search support' adds minor clutter without clear utility, slightly reducing 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?
For a simple read tool with one parameter and no output schema, the description is adequate but incomplete. It covers the basic action and parameter, but lacks details on return format, error handling, or the implications of 'legacy', which could affect agent usage given the sibling tools available.
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 the 'search' parameter as an optional query. The description adds minimal value by reiterating 'optional search filter' and noting 'legacy with search support', but doesn't provide additional syntax, format, or behavioral context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and resource 'notes in the vault', specifying it retrieves all notes with optional filtering. It distinguishes from siblings like 'get_note' (single note) and 'get_recent_notes' (subset), but doesn't explicitly contrast with 'search_vault' or 'find_related_notes'.
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 all notes, optionally filtered by search, but provides no explicit guidance on when to use this tool versus alternatives like 'search_vault' or 'find_related_notes'. The mention of 'legacy with search support' hints at context but doesn't clarify exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool 'Handles common daily note naming conventions and file locations,' which adds useful behavioral context about how it locates notes. However, it doesn't cover other aspects like error handling (e.g., what happens if no note exists for the date), performance, or permissions, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and front-loaded: the first sentence states the core purpose, and the second adds valuable context without redundancy. Every sentence earns its place by providing essential information, making it efficient and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is somewhat complete but has gaps. It covers the purpose and behavioral context (handling conventions), but without annotations or output schema, it doesn't fully address what the tool returns (e.g., note content or metadata) or potential limitations, making it minimally adequate.
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 'date' parameter well-documented in the schema itself. The description doesn't add any parameter-specific details beyond what the schema provides (e.g., it doesn't explain the 'common naming conventions' in relation to the date parameter). Since the schema does the heavy lifting, 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.
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: 'Get daily note for a specific date.' It specifies the verb ('Get') and resource ('daily note'), and distinguishes it from general note tools like 'get_note' by focusing on daily notes. However, it doesn't explicitly differentiate from 'get_recent_notes' or 'list_notes' in terms of scope, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'specific date' and 'common daily note naming conventions and file locations,' suggesting it's for retrieving notes organized by date. However, it lacks explicit guidance on when to use this versus alternatives like 'get_note' (for general notes) or 'get_recent_notes' (for recent notes without date specificity), 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 the full burden of behavioral disclosure. It adds valuable context about pagination ('to prevent context overflow') and default behavior ('Shows immediate contents by default'), which aren't in the schema. However, it doesn't cover aspects like error handling, permissions needed, rate limits, or what happens with invalid paths. For a tool with no annotations, this is adequate but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise with two sentences that efficiently convey key information: the core function and important behavioral traits. It's front-loaded with the main purpose and avoids any redundant or unnecessary wording. Every sentence earns its place by adding value beyond the tool name.
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 (4 parameters, no output schema, no annotations), the description is minimally complete. It covers the purpose and key behavior (pagination, default scope) but lacks details on return values, error cases, or integration with siblings. Without an output schema, it should ideally hint at the response format, but it's adequate for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 4 parameters. The description adds no specific parameter semantics beyond what's in the schema (e.g., it doesn't explain 'path' format or 'limit' constraints further). With high schema coverage, the baseline is 3, and the description doesn't compensate with extra details, but it doesn't detract either.
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 'List directory contents' with specific functionality ('with pagination to prevent context overflow') and scope ('Shows immediate contents by default'). It distinguishes from siblings like 'list_notes' by focusing on directory contents rather than notes, though it doesn't explicitly name alternatives. This is clear but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'with pagination to prevent context overflow' and 'Shows immediate contents by default', suggesting it's for browsing directories with control over output size. However, it doesn't explicitly state when to use this tool versus alternatives like 'list_notes' or 'search_vault', nor does it provide exclusions or prerequisites. Usage is implied but not fully articulated.
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 upsert behavior and mentions content and frontmatter, but lacks details on permissions, error handling, rate limits, or what happens to existing frontmatter during updates. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and uses only two concise sentences that earn their place: the first states what it does, and the second explains the upsert behavior. There is zero waste or 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 complexity (mutation with 3 parameters, nested objects, no output schema, and no annotations), the description is adequate but incomplete. It covers the basic operation and upsert logic but lacks details on permissions, error cases, or return values, which are important for a mutation tool without structured output documentation.
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 (path, content, frontmatter). The description adds marginal value by mentioning 'content and frontmatter' and implying the path identifies the note, but doesn't provide additional syntax, format, or constraints beyond what the schema specifies. Baseline 3 is appropriate when 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 specific verb ('create or update') and resource ('a note with content and frontmatter'), distinguishing it from siblings like 'get_note' (read-only) or 'delete_item' (removal). It explicitly mentions the upsert behavior, which differentiates it from simple create or update 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 provides clear context for when to use this tool ('Performs upsert operation - creates if doesn't exist, updates if it does'), which helps differentiate it from alternatives like 'write_file' (generic) or 'get_note' (read-only). However, it doesn't explicitly state when NOT to use it or compare with all relevant siblings (e.g., 'write_file' for non-note files).
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-local-rest-api-mcp MCP server](https://glama.ai/mcp/servers/j-shelfwood/obsidian-local-rest-api-mcp/badges/card.svg)](https://glama.ai/mcp/servers/j-shelfwood/obsidian-local-rest-api-mcp)

Score Badge

Copy to your README.md:

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

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