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.
This server publishes no instructions, or was last inspected before Glama recorded them.
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.