obsidian-tc
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
obsidian-tc 1.28.4 — an MCP server over Obsidian vaults. Tools are authorized per call (scopes + folder ACL); resources are vault notes. After acting on a retrieved chunk, report whether it helped via record_retrieval_feedback — retrieval quality is learned from that signal and nothing else supplies it.
Capabilities by domain (read obsidian-tc://catalog for the full caller-visible list):
Notes: Read, write, move, copy, and delete vault notes, and restore them from snapshots. (e.g. list_notes, read_note, write_note, patch_note)
Metadata: Frontmatter, properties, and tags. (e.g. read_frontmatter, update_frontmatter, add_tag, find_notes_by_property)
Links: Backlinks, outgoing links, orphans, link maintenance, and link-graph health. (e.g. get_backlinks, get_outgoing_links, find_orphans, vault_health_score)
Search: Full-text, regex, semantic, and query-language search. (e.g. search_text, search_regex, search_semantic, search_vault)
Vault: Vault registry, runtime registration, and the search index. (e.g. add_vault, list_vaults, index_vault, reload_vault)
Attachments: Attachment files and OCR. (e.g. list_attachments, get_attachment, ocr_attachment)
Structured documents: Bases, canvases, Excalidraw drawings, Kanban boards, and markdown tables. (e.g. read_base, create_canvas, read_kanban_board, format_table)
Workspace: Bookmarks, workspaces, and periodic notes. (e.g. list_bookmarks, add_bookmark, list_workspaces, get_periodic_note)
Automation: Commands, templates, Dataview, MakeMD, QuickAdd, tasks, bundles, and URIs. (e.g. list_commands, execute_command, list_templates, execute_template)
Git: Vault version control via the Obsidian Git companion bridge. (e.g. git_status, git_diff, git_log, git_commit)
Knowledge: Knowledge graph, entities, memory, work-memory, capture queue, sessions, and provenance. (e.g. create_entity, link_entities, add_observation, query_entity_graph)
External docs: Search and triage the vendor and external-docs corpus. (e.g. knowledge_search, knowledge_get_critical)
Admin: Server config, ACL inspection, health, and metrics. (e.g. server_health, get_index_status, inspect_acl, get_metrics)
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": true
} |
| resources | {
"subscribe": true,
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| find_capabilityA | Search this server's full tool catalog by natural-language query and return the best-matching capabilities (name + one-line summary). Use it to discover which tool to call, then describe_capability for its schema and call_capability to run it. To enumerate the whole caller-visible catalog grouped by domain instead of searching it, read the obsidian-tc://catalog resource. |
| describe_capabilityA | Return the full input schema, required scopes, and safety hints (read-only / destructive) for a single capability by name. |
| call_capabilityA | Invoke a capability by name with its arguments. Routes into the same authorization, ACL, HITL, idempotency, and rate-limit pipeline as a direct tool call, so every safety gate applies and the target's own schema validates the arguments. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| summarize_note | Summarize a single vault note. |
| find_connections | Find and explain how notes relate to a topic or note. |
| decompose_and_research | Answer a compound question by decomposing it into facets, retrieving per facet, and synthesizing with citations and open questions. |
| recent_changes_digest | Summarize what changed in the vault recently. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Tool catalog | Every capability visible to this caller, grouped by domain (name + one-line summary, no schemas). See also find_capability for a query-driven search over the same catalog. |
TDQS
Scored across 3 tools
Each tool has a clearly distinct role: find_capability discovers, describe_capability inspects, call_capability executes. There is no overlap or ambiguity between them.
All three tools follow the same verb_noun snake_case pattern with a consistent capability-related noun. The naming is uniform and predictable.
Three tools is well-scoped for a capability routing server; each tool covers one essential step in the discover-describe-invoke workflow. No redundant tools exist.
The tool set covers the full workflow of finding, understanding, and calling a capability, with catalog enumeration handled via a resource. There are no obvious missing operations for the server's stated purpose.