obsidian-brain

by sweir1

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.7.24
Disambiguation5/5
Each tool has a clearly distinct purpose: note CRUD, linking, search, graph analysis, indexing, and specialized queries. Even overlapping areas like search and dataview_query are delineated by their descriptions. No two tools appear to do the same thing.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern (e.g., create_note, find_path_between). No mixed conventions or inconsistencies.
Tool Count5/5
18 tools is slightly above the typical 3-15 range, but each tool addresses a distinct aspect of vault interaction, such as note management, linking, searching, graph analysis, and indexing. The count is well-justified for the domain's complexity.
Completeness4/5
The tool surface covers core note operations (CRUD, search, linking, graph analysis, indexing) and includes specialized query systems (Bases, Dataview). Minor gaps exist (e.g., bulk operations, attachment management), but the set is comprehensive for typical agent workflows.
Average 4.3/5 across 18 of 18 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 3 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on May 16, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Apache 2.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.
View related servers

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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses that the tool 'appends the link to the source note and records the edge in the graph,' and mentions a dryRun parameter. However, it does not specify permissions, reversibility, idempotency, or what happens if a link already exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence states the core action, the second explains the effect (appending and recording). Information is 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 description explains the action and side effects, but with no output schema and no annotations, it should clarify the return value (e.g., success message or the appended line). It also omits error conditions, such as when source or target notes do not exist, and does not mention prerequisites (e.g., notes must exist).
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 baseline is 3. The description adds meaning by explaining the overall purpose of the context parameter ('why they're connected') and the effect of dryRun. However, it does not provide additional nuance beyond the schema for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action: 'Add a wiki-link from one note to another with a context sentence.' It clearly identifies the verb (add), resource (wiki-link), and the linking action, distinguishing it from sibling tools like create_note or edit_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., find_connections). The description implies usage for creating connections, but does not provide contexts where it is appropriate or when to avoid it, nor mentions prerequisites or alternatives.
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, the description fully handles behavioral disclosure. It details truncation behavior in full mode (maxContentLength, truncated flag) and the response structure including context.next_actions. No side effects are relevant since it's a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences) and front-loads the main purpose. It could be slightly more structured (e.g., bullet points for modes), but it is efficient and clear.
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 has no output schema and three parameters, the description adequately covers the behavior, output structure, and follow-up suggestions. It is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining that 'name' can be a path, filename, or fuzzy match, and clarifies the behavior of 'mode' and 'maxContentLength' beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read a note's content' and distinguishes between brief and full modes, specifying what each returns. However, it does not explicitly differentiate from sibling tools like search or list_notes, which also retrieve note information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use brief vs full mode and mentions follow-up actions from context.next_actions. However, it lacks guidance on when to use this tool over alternatives (e.g., search for finding notes, list_notes for listing).
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?
Discloses immediate indexing and title auto-injection, but does not mention error conditions (e.g., overwrite behavior) or required permissions. As no annotations exist, more details would enhance 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?
Three concise sentences with no redundancy. Each sentence adds essential information: creation, indexing, and auto-injection nuance.
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?
Covers parameters well but omits return value (e.g., note path or ID) and does not specify behavior on duplicate titles. Given no output schema, this gap is notable.
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?
Adds significant value beyond schema: explains title as filename and frontmatter injection, clarifies content excludes frontmatter, and describes directory and frontmatter behavior. Schema coverage is 100%, but description elevates 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 verb (create) and resource (new note in vault), and distinguishes from sibling tools like edit_note and delete_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (create a new note) but lacks explicit when-not-to-use or alternatives. It provides behavioral details like auto-injection but no direct comparison to siblings.
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 is adequate: it notes the default for includeStubs and what it does. However, it omits details like pagination behavior, ordering, or error conditions, which would help 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?
Two sentences, no redundant words, and the important instructions about includeStubs are front-loaded. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not explain what is returned (e.g., full note objects vs. names), nor does it mention empty results or ordering. It covers filter options but leaves gaps for a complete invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context for includeStubs and mentions limit default but does not significantly enrich the schema's definitions for directory or tag.
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 explicitly states 'List notes in the vault' with optional filters by directory or tag, clearly defining the verb and resource. It distinguishes from sibling tools like search or read_note as a listing 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?
The description gives clear guidance on using includeStubs and filter options but does not explicitly contrast with sibling tools (e.g., when to use this vs. search). The context is implied but could be more direct.
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 prerequisites but does not confirm it is read-only or mention potential failure modes. It adds some context but could be more thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. The first states the core functionality, the second states prerequisites. Well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not specify the return format or structure, which is a gap given no output schema. It also lacks error handling info. Adequate but not fully complete for an agent.
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?
There are no parameters (0), so the description does not need to explain parameters. The baseline is 4, and the description adds context about what the return includes, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the currently open note in Obsidian with cursor position and selection. It uses specific verbs and resource, distinguishing it from siblings like read_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use (to get the active note) and prerequisites (requires plugin and running Obsidian). It does not explicitly state when not to use or list alternatives, but the sibling tools imply alternatives.
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?
Given no annotations, the description discloses key behaviors: preview expiration (5 min) and error on file change. It doesn't detail other aspects like idempotency or asynchronous execution, but covers the most critical constraints.
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?
Three sentences with no wasted words. Front-loaded with the main action, followed by prerequisite, expiration, and error handling. Efficient and clear.
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 tool with one parameter and no output schema, the description covers prerequisite, parameter, expiration, and error handling. Minor gap: no mention of success behavior or return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description repeats the schema's parameter info (the previewId) without adding new semantics or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it applies a previously previewed edit, linking to the sibling edit_note. It specifies the verb 'apply' and the resource 'preview', making the action 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?
It explains the prerequisite (obtain previewId from edit_note with dryRun: true) and handles failure scenarios (expiry, file change). Lacks explicit when-not-to-use but provides strong contextual cues.
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?
No annotations are provided, so the description carries the full burden. It explains the default exclusion of stub nodes, why they are excluded (degree-1 dead ends), and the option to include them. Also describes that it returns simple paths up to maxDepth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an additional sentence about stubs, all front-loaded. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is quite complete. It covers core function, parameters, and a key behavioral detail. Could mention return format, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value beyond schema by explaining the default behavior of includeStubs and the rationale for stubs. Brief explanation of includeCommon also provided.
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 starts with 'Find link paths between two notes,' which is a specific verb+resource. It clearly distinguishes from siblings like 'find_connections' and 'list_notes' by focusing on path finding between two specific 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 provides implicit usage context (finding paths between notes) but does not explicitly state when to use this tool over alternatives or when not to use it. No mention of other tools for path finding.
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?
In the absence of annotations, the description fully discloses key behaviors: immediate in-place rewriting of wiki-links (detailing link variants), frontmatter title auto-rewrite logic under specific conditions, and the dryRun option. Response format is also mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, then explains behavior and response in 3 concise sentences. Every sentence adds value without repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately covers the tool's behavior, parameter implications, and return structure. Could mention error handling or constraints, but overall complete for its complexity.
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 detailed parameter descriptions. The tool description adds no extra meaning beyond what the schema provides, so it meets baseline but does not exceed.
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 starts with a clear verb+resource: 'Rename or move a note.' It distinguishes itself from siblings like edit_note, delete_note, etc., by explicitly describing its core renaming/moving functionality and the link-rewriting behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for renaming/moving notes but does not explicitly state when to use it vs. alternatives or provide exclusion criteria. The sibling list is provided but not referenced.
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?
With no annotations, the description fully discloses behavioral traits: default mode, RRF fusion, chunk-level semantics, dedup behavior, unique parameter effects, fulltext note-level-only, and response format including context.next_actions. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly detailed (~150 words) but well-structured: starts with purpose, then mode explanations, unique behavior, fulltext limitation, and response format. Each sentence adds value, though slightly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers response format and context.next_actions. It explains mode, unique parameter, and limitations. Minor gaps: pagination or sorting not mentioned, but overall complete for search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline of 3. The description adds significant meaning beyond schema: explains hybrid RRF, semantic vs fulltext, chunk-level dedup, unique parameter details, and response context. Adds value beyond bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches vault notes and explains three search modes (hybrid, semantic, fulltext) with specific behaviors. It differentiates mode usage within the tool but does not explicitly distinguish from sibling tools like list_notes or base_query.
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 explicit guidance on when to use each search mode: hybrid for most queries, semantic for abstract, fulltext for exact phrases. It also explains the unique parameter behavior. However, it does not mention when not to use the tool or alternatives among siblings.
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, the description carries full burden. It discloses filtering defaults (minIncomingLinks: 2), normalization of bridging scores, stub exclusion, and the rationale for defaults. It does not explicitly state read-only behavior or output format, but the behavioral details are 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 paragraph of 6 dense sentences, front-loading the main purpose and then efficiently detailing each parameter's effect. No redundant information; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description is mostly complete but lacks an explanation of the return format, error conditions, or prerequisites (e.g., existence of graph structure). This minor gap prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds substantial meaning: mapping metric enum to algorithms, explaining the purpose of minIncomingLinks and includeStubs beyond defaults, and clarifying limit and themeId. Every parameter's behavior is enriched.
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 ranks notes by importance using two specific metrics (influence and bridging), defined in graph theory terms. It distinguishes itself from sibling tools like find_connections or search by focusing on centrality-based ranking.
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 explains how to choose between metrics (influence vs bridging) and parameter effects, but does not explicitly state when to use this tool over sibling tools like find_connections or dataview_query. Usage context is implied but not contrasted.
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. It discloses behavioral traits: re-embeds only changed notes, prunes stubs, and conditionally runs community detection only if something changed or if resolution is passed. This is good transparency, though it could mention safety (non-destructive) or 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 consists of two sentences, the first front-loading the main purpose and actions, the second detailing the optional parameter. Every sentence adds essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple sub-actions) and the absence of an output schema, the description is fairly complete. It explains behavior for both change and no-op scenarios. However, it does not mention what the tool returns (e.g., reindex summary), which would be helpful for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter `resolution` is fully described in the schema (100% coverage). The description adds significant value by explaining that omitting it skips community detection on no-op reindexes, while passing a value forces a rerun and tunes granularity. This goes beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool re-indexes the vault and lists specific actions (re-embeds changed notes, prunes orphan stubs, re-runs community detection). The verb 're-index' and noun 'vault' are specific, and the description distinguishes it from sibling tools like 'index_status'.
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 explains when to use the tool (re-indexing) and the effect of the `resolution` parameter, but does not explicitly state when not to use it or mention alternatives (e.g., for status checks use 'index_status'). The guidance is present but not comprehensive.
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, the description carries full burden. It discloses stub exclusion behavior, optional includeStubs, and response wrapping with context.next_actions. However, it does not explicitly state whether the operation is read-only or mention any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. First sentence states purpose, second adds optional return format and response wrapping, third explains stub exclusion. Front-loaded and efficient.
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 description adequately covers key aspects: purpose, parameters, response format, and follow-up hints. Without an output schema, it provides enough context for an agent to select and invoke the tool correctly. Slight miss on explicit performance or auth hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value beyond schema by explaining the default behavior of excludeStubs and the response structure including next_actions hints.
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 'Find notes linked to (from or to) a given note, up to N hops,' specifying action, resource, and constraints. It distinguishes from siblings like find_path_between and detect_themes by noting follow-up suggestions.
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 explicit context for usage, including follow-up actions like clustering or path tracing. It does not explicitly state when not to use but offers alternative suggestions in the response context.
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?
No annotations provided, so description carries full burden. Discloses plugin dependency, limitations of Obsidian API, unsupported construct errors, timeout behavior (only cancels HTTP wait, not plugin execution), and return format. Exceptionally transparent.
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?
Front-loaded with purpose and prerequisites. Well-structured with clear sections. Slightly verbose on unsupported constructs list, but justified by complexity. No wasted sentences.
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?
Complete coverage for a complex tool: prerequisites, parameter details, return structure, error cases, limitations, and timeout behavior. No output schema, but description adequately fills the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters (baseline 3). Description adds value by clarifying mutual exclusivity of file/yaml, giving example for view, and explaining timeoutMs behavior beyond 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?
Explicitly states the verb 'evaluate', the resource '.base file', and the output 'return its rows'. Clear distinction from sibling tools by focusing on Obsidian Bases, with prerequisites listed.
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 prerequisites (plugin, Obsidian version, core plugin) and when-not-to-use (unsupported constructs return 400). Suggests using limit: for open-ended queries. However, lacks direct comparison to sibling tool dataview_query.
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?
With no annotations, the description fully discloses behaviors: defensive newline in append, fuzzy trailing punctuation handling, heading duplication throwing MultipleMatches, atomic edits via 'edits' array, dry-run preview, and detailed patch_heading scope behavior. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed and front-loaded with a summary of modes, but it is verbose. Every sentence adds necessary detail given the tool's complexity, though a more structured format (e.g., bullet points) could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 18 parameters, no output schema, and complex behavior, the description covers all modes, error handling, edge cases, and best practices. It is sufficiently complete for an AI agent to use the tool effectively.
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?
While schema coverage is 100%, the description adds significant meaning beyond schema labels, such as explaining fuzzy threshold recommendation, scope='body' behavior, and valueJson nuances. This adds value for correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Modify an existing note' and details six distinct edit modes (append, prepend, replace_window, etc.), making the tool's purpose specific and distinct from sibling tools like create_note, delete_note, and move_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each edit mode and provides contextual guidance (e.g., fuzzy trailing punctuation handling, scope for section replacement). However, it does not explicitly compare with alternative tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: the return shape (discriminated union with details for each kind), the timeout behavior (only cancels HTTP wait, not the query itself), and the need for specific plugins. This is comprehensive and honest.
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 well-structured and front-loaded with purpose, then prerequisites, then return shapes. It is slightly long but every sentence is informative. Could be tightened slightly, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (multiple output kinds, no output schema, external dependencies), the description is remarkably complete. It covers prerequisites, return structures, timeout nuance, and best practices. No gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value: example DQL for 'query', explanation of 'source' as optional origin for relative links, and timeoutMs details (default, no cancellation). This goes well beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs a Dataview DQL query against the vault, with a specific verb 'Run' and resource 'Dataview DQL query'. It distinguishes itself from sibling tools like search or list_notes by focusing on Dataview's query language.
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 explicit prerequisites (plugin versions, Obsidian running, Dataview enabled) and practical guidance like using LIMIT and understanding timeout limitations. It lacks explicit 'when not to use' or direct alternatives, but the context is clear enough.
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?
No annotations provided, so description carries full burden. Discloses permanence, what gets destroyed (file, edges, embedding, node), guard condition, and suggests next steps.
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?
Three sentences, no fluff. Front-loaded with main action. Every sentence provides value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, it thoroughly describes the effect and even suggests follow-up. Covers behavior fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds meaning: 'confirm: true' guard, 'dryRun' reports what would be deleted. Adds context beyond 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?
Clearly states 'Permanently delete a note' and specifies what is removed (file, index rows). Distinguishes from siblings like move_note or edit_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly requires 'confirm: true' to guard against accidents and suggests a follow-up action (rank_notes) after deletion. Does not explicitly state when not to use, but provides clear context.
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?
With no annotations, the description fully discloses that it is read-only and non-mutating, listing all reported components. This provides complete transparency about 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, well-structured sentence that front-loads the purpose and then lists the reported items concisely. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully explains the return values by listing all reported fields. It covers all necessary information for a diagnostic tool, including edge cases like skipped chunks and errors.
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 no parameter description is needed. The description adds value by detailing what the tool reports, compensating for the lack of a output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reports the current state of the vault index, listing specific items like embedder model, dimensions, counts, and reindex status. This distinguishes it from siblings like 'reindex' which performs an action, and other read-only tools like 'read_note' which focus on content.
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 explicitly states it is read-only and does not mutate anything, guiding when to use it for checking index state without side effects. However, it does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details read-only nature, caching, staleMembersFiltered, filtering of stubs, and modularity warnings. Very comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with main purpose and then provides necessary details in a logical order. Every sentence adds value; no fluff.
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?
Despite no output schema, description explains response contents (staleMembersFiltered, warning, modularity) and edge cases. Fully adequate for a read-only tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds meaning for both parameters: themeId explains drilling, includeStubs explains default behavior and caching implications.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists auto-detected topic clusters (specific verb+resource). It distinguishes itself from siblings like reindex by noting that computation is done elsewhere.
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?
Explicitly tells when to use reindex instead for recomputation. Also explains drilling into a cluster with themeId or label.
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-brain MCP server](https://glama.ai/mcp/servers/sweir1/obsidian-brain/badges/card.svg)](https://glama.ai/mcp/servers/sweir1/obsidian-brain)

Score Badge

Copy to your README.md:

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

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/sweir1/obsidian-brain'

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