Obsidian Second Brain MCP

by theon199

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools target distinct resources and actions: read/create/update/organize for notes, daily_note for the daily note, manage_tasks for tasks, and vault_overview/search for broader queries. Slight overlap exists between update_note's task-updating feature and manage_tasks, but descriptions clarify the intended use.
Naming Consistency4/5
The majority follow a verb_noun pattern (read_note, create_note, update_note, organize_note, manage_tasks, suggest_use_cases, run_obsidian_command, search_notes). Two exceptions, daily_note and vault_overview, use noun-based naming, creating minor but tolerable inconsistency.
Tool Count5/5
Ten tools is well within the ideal 3-15 range and each tool covers a meaningful aspect of vault interaction without redundancy. The count feels appropriately scoped for a second-brain management server.
Completeness4/5
The server covers note CRUD (including trash), daily notes, task management, search, and vault-level analytics, covering primary workflow needs. Minor gaps exist such as no explicit list-all-notes operation (search compensates) and no permanent deletion by design, but the surface is largely complete.
Average 3.6/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false, and the description's 'change' aligns with a mutable operation. However, beyond this, the description discloses no additional behavioral details—such as whether listing tasks has side effects, whether updates modify note files, or what happens with custom status. Since annotations already cover the basic mutability, the description adds minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that packs the essential purpose without any extraneous words. It is concise and easy to parse, earning full marks for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is woefully incomplete for a tool with 9 parameters and complex actions. It does not clarify which parameters apply to 'list' versus 'update', nor how filter, done, status, ref, file, path, line, and daily relate to the actions. Without additional documentation or schema descriptions, an agent cannot correctly select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameter meanings. It fails to do so. None of the nine parameters (ref, done, file, line, path, daily, filter, status, action) are explained. The description only names high-level actions, leaving the agent without any insight into how to construct a valid invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's dual function: 'List tasks or change a task's completion/custom status.' The verb 'List' and 'change' specify exact actions, and the resource 'tasks' is distinct from sibling tools focused on notes. This makes it immediately clear what the tool does and how it differs from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It doesn't mention that this is for task management within notes, nor does it reference sibling tools like read_note or update_note. There is no 'when to use' or 'when not to use' context, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the list of aspects covered (size, structure, tags, properties, etc.), providing useful scope information but no additional behavioral details like output format or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action verb, no filler. It earns its place by summarizing the tool's scope efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only summary tool with a 1-parameter input and output schema provided, the description covers the core purpose. However, it omits explanation of sampleLimit and any contextual guidance on when a vault overview is appropriate. The output schema likely covers return values, so that gap is mitigated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is self-documenting for constraints (integer, 1-200, default 30) but includes no description for sampleLimit. The tool description does not mention this parameter either, so the agent must infer its meaning from the parameter name. With 0% schema description coverage, the description fails to compensate.
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 uses the specific verb 'Summarize' and clearly identifies the resource (vault) and scope (size, structure, tags, properties, link health, tasks). It does not explicitly compare with sibling tools, but the vault-level scope inherently differentiates it from note-centric siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as search_notes or read_note. The description merely states what it does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide the read/write safety profile (readOnlyHint false, idempotentHint false, destructiveHint false). The description adds the 'active daily note' scoping and lists the 'open' action, but it does not disclose side effects like whether append/prepend requires content or what 'open' does. This is limited additional context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently lists all four actions and the target resource. There is no filler or repetition.
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?
Although an output schema exists and annotations are present, the description omits important usage details: when content is required, what 'open' behavior entails, and what happens if no active daily note exists. It is minimally viable but incomplete for a multi-action tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description never mentions the 'content' parameter or its role. While the action enum values are fairly self-explanatory, the content field's requirement for append/prepend is left entirely to inference, which is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the resource ('the active daily note') and enumerates four concrete operations: read, open, append, and prepend. This distinguishes it from sibling tools like read_note or update_note, which target general notes rather than the active daily note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus alternatives such as read_note or update_note. The phrase 'active daily note' implies a specific use case, but there are no explicit conditions, exclusions, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows commands may mutate state. The description adds valuable context that permanent delete, eval, and dev controls are blocked, which is a safety-relevant limitation beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the verb and resource, followed by safety restrictions. Every word carries meaning; there is no fluff or repetition.
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?
This is a high-risk, arbitrary command execution tool, yet the description omits examples, arg construction rules, or scenarios where it should NOT be used. The output schema exists but doesn't compensate for the missing usage semantics, making the description incomplete for an agent to safely and correctly invoke commands.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description must compensate but only says 'using an argument array', which adds almost no meaning beyond the schema's array-of-strings definition. It does not explain how to order args, whether the first element is the command name, or what timeoutMs controls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Run' and identifies the resource as 'Obsidian CLI or plugin commands', clearly distinguishing it from sibling note/task tools. It also communicates the scope ('broad') and blocked categories, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives like 'read_note' or 'vault_overview'. The only implied guidance is the word 'broad', and the blocked categories (permanent delete, eval, dev controls) are restrictions, not usage directions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a mutating tool. The description adds no further context about when destruction occurs (e.g., with overwrite=true) or any other behavioral traits like default path or open behavior. It doesn't contradict annotations, but it also doesn't enrich the safety profile beyond what annotations already provide.
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, grammatically simple sentence that front-loads the action and key options. It's not bloated, but it sacrifices necessary detail for brevity. Given the complexity of the tool, it could be slightly longer without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters, nested properties, and an output schema, yet the description only explains the creation source and properties. It fails to mention path, overwrite, open behavior, or what happens if no content/template is provided. The destructiveHint annotation warns about risk, but the description doesn't define when the destruction happens. This leaves a significant knowledge gap for an agent to invoke it safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 7 parameters with 0% description coverage, so the description must compensate. It mentions content, template, and properties, which are core parameters, but completely omits name, open, path, and overwrite. It doesn't clarify that content and template are alternatives, nor does it explain the critical 'overwrite' parameter that aligns with the destructiveHint. The added meaning is too sparse for a 7-parameter tool.
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 has a specific verb+resource ('Create a note') and distinctly scopes the action: 'from content or an Obsidian template and optionally set properties.' This clearly distinguishes it from siblings like update_note and read_note, which are about modifying or reading existing notes. No ambiguity.
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 verb 'Create' implies this tool is used for new note creation, and the sibling list makes it obvious when to use it compared to update_note or organize_note. There is no explicit 'when not to use' or alternative mentions, but the context is clear enough that an agent can infer usage from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds the list of returned components but does not disclose behavior for edge cases like missing files or the need to provide at least one parameter. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that clearly states the action and its scope with no filler. It is front-loaded with the verb 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema is present and the annotations provide strong safety context, so the description is not required to explain return values or safety. The main gap is the lack of clarity on whether at least one of file/path must be provided and how they interact, but the overall tool is simple and well-covered by structured metadata.
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 descriptions for both parameters (file and path) are complete and self-explanatory, providing 100% coverage. The description adds no additional meaning about the parameters, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads a note and specifies the additional components returned (metadata, outline, properties, outgoing links, backlinks). It is distinct from sibling create/update tools, though it does not explicitly differentiate from search_notes or vault_overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. It is implied that this tool is for reading a single note's full context, but there is no mention of when to prefer it over search_notes or how to choose between the file and path parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the agent knows this modifies content. The description adds that it can append, prepend, or update tasks, which is useful, but it does not disclose whether changes are reversible, whether property operations overwrite or merge, or whether task updates target lines/refs. With only a broad destructive hint, the description provides some behavioral context but leaves important details unclear.
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, compact sentence listing the three primary operations. It is front-loaded with the verb and resource, and every word contributes meaning. No wasted text or repetition of schema data.
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 (supports multiple operation types) and the presence of an output schema (which likely documents return values), the description covers the main operation categories but lacks explicit guidance on when to use which operation mode, prerequisites like needing an existing note, and what happens if both append and prepend are provided. The annotations cover destructive intent but not details like whether file/path are mutually required. It is adequate but not highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage and clarifies param meanings (e.g., 'file' as link-resolved name, 'path' as vault-relative). The description adds semantic grouping: append/prepend content vs. property changes vs. task updates, which helps the agent understand the high-level intent behind the parameters. It does not fully explain the task object's ref/status/line semantics, but the schema's property descriptions plus the overview in the description are adequate for a baseline above 3.
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 'Append/prepend content, change properties, or update a task in a note' clearly identifies the verb (append/prepend/update) and the resource (note), and lists specific operations. It distinguishes itself from read_note and create_note, though the sibling tools like manage_tasks and organize_note overlap somewhat with the 'update a task' and 'change properties' functions, so it isn't fully explicit about boundaries.
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 modifying existing notes (append/prepend/properties/task updates), but does not explicitly state when to use this tool versus alternatives like manage_tasks (for task-specific updates) or organize_note (for reorganization). There is no when-not-to-use guidance or mention of the file/path requirements for targeting an existing note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds meaningful behavioral context beyond this by specifying that the search returns optional matching-line context and can filter by folder, which are not derivable from the annotations alone. No contradiction 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?
The description is a single, front-loaded sentence that efficiently conveys the core function and two key options. No words are wasted; every phrase adds value. It is perfectly concise for a simple search tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which covers return values), the tool has 5 parameters with zero schema descriptions, and the description only partially compensates by naming two of them. It omits critical context such as case sensitivity, limit behavior, and how the query parameter works. For a search tool of this complexity, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, placing the burden on the description to explain all 5 parameters. The description only references two parameters (context and folder) via "matching-line context" and "folder filtering". The other parameters (query, limit, caseSensitive) remain unexplained, leaving significant gaps in the agent's understanding of how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: "Search the vault" with optional context and folder filtering. This unambiguously distinguishes it from siblings like read_note (specific note retrieval) and vault_overview (overview), making the purpose immediately clear.
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 (when you need to search the vault) but provides no explicit guidelines on when to use this tool versus alternatives such as read_note or vault_overview. It mentions optional folder filtering and matching-line context, but does not state exclusions or alternative tools, leaving the agent to infer the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds contextual detail about using 'native graph and organization signals' and ranking workflows, which gives insight into the tool's internal logic without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence. It front-loads the action ('Analyze') and includes no filler, making every word valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and simple single-parameter schema, the description sufficiently explains the core purpose. It doesn't elaborate on what qualifies as a 'contextual second-brain workflow' or detail the output format, but those are partially covered by the output schema and the overall context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not mention the 'sampleLimit' parameter at all. Although the schema provides min/max/default, the description fails to explain how sampleLimit affects the ranking or what is being sampled, leaving this ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's function: analyze native graph and organization signals and rank contextual second-brain workflows. It uses specific verbs ('analyze', 'rank') and distinguishes itself from sibling tools like note reading/writing or task management.
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 getting workflow recommendations based on graph/organization signals, but it doesn't explicitly state when to use it versus alternatives like vault_overview or search_notes. No exclusions or alternative references are provided.
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?
Annotations already mark destructiveHint=true, and the description adds crucial context: 'Permanent deletion is never used.' This clarifies that trash is reversible, providing a valuable safety guarantee beyond the structured annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the main operations and then a safety note. Every word earns its place with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool supports three distinct operations (move, rename, trash) with different parameter needs, and the description covers the core purpose and safety. The output schema exists, so return values are covered. Minor gap: it doesn't explicitly map each action to its required parameters, but the parameter names and enum values are self-explanatory.
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?
Per context signals, schema description coverage is 100%, so the schema carries the parameter semantics. The description adds no extra parameter-level guidance, but the baseline of 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool can move, rename, or trash a note, with a strong safety guarantee that permanent deletion is never used. This specific verb set and resource ('note') distinguish it from siblings like read_note, create_note, and update_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 title 'Organize or Trash Note' and the description clearly imply when to use it: for moving, renaming, or trashing notes. It doesn't explicitly name alternatives or exclusions, but the action verbs make the intended usage obvious relative to the sibling tools.
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-second-brain-mcp MCP server](https://glama.ai/mcp/servers/theon199/obsidian-second-brain-mcp/badges/card.svg)](https://glama.ai/mcp/servers/theon199/obsidian-second-brain-mcp)

Score Badge

Copy to your README.md:

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

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