Is your feature request related to a problem?
External MCP-compatible clients (Claude Desktop, n8n, custom agents, voice triggers) have no way to discover or invoke ObsidiBot skills remotely. Vault workflows are locked inside the Obsidian UI, even when the underlying skill logic would be perfectly useful from an external caller.
Describe the solution you'd like
Add an optional MCP server to ObsidiBot that exposes the vault's Skills folder as callable tools, enabling external MCP-compatible clients to discover and invoke ObsidiBot skills remotely.
The Skills folder acts as the trust boundary by design — it is already a user-curated allowlist. Anything the user wants externally accessible gets wrapped in a skill; everything else stays internal. No separate security configuration required.
Describe alternatives you've considered
Exposing raw Obsidian commands via MCP was considered but explicitly ruled out. ObsidiBot already publishes every Obsidian command — including third-party plugins — which creates a powerful but unbounded surface. Skills-only keeps the external API intentional and user-controlled.
Use Case
- Any MCP-compatible client can discover and invoke vault workflows
- Skills become API endpoints, not just slash-menu shortcuts
- The community skills marketplace gains a second dimension: shared skills are also shared capability endpoints
- Remote and mobile triggering without solving full mobile plugin parity
- One skill definition, multiple callers (human via slash menu, external agent via MCP) — consistent behavior
Additional Context
This builds naturally on the existing skills infrastructure. The community marketplace (#62, watch system) and scoped permission model (#61) would both benefit from a well-defined external invocation surface.
Raw Obsidian command exposure is explicitly out of scope. Users who want to expose a specific command externally should wrap it in a skill first.
Implementation Suggestions
The implementation surface is narrow:
- Skill discovery — enumerate the skills folder and expose each skill as an MCP tool definition
- Skill invocation — route incoming MCP tool calls through the existing param/interpolation/autorun pipeline
- Result return — return skill output over the MCP transport
The heavy lifting (skill parsing, parameter interpolation, execution) already exists. This is primarily an MCP transport layer over existing functionality.
Is your feature request related to a problem?
External MCP-compatible clients (Claude Desktop, n8n, custom agents, voice triggers) have no way to discover or invoke ObsidiBot skills remotely. Vault workflows are locked inside the Obsidian UI, even when the underlying skill logic would be perfectly useful from an external caller.
Describe the solution you'd like
Add an optional MCP server to ObsidiBot that exposes the vault's Skills folder as callable tools, enabling external MCP-compatible clients to discover and invoke ObsidiBot skills remotely.
The Skills folder acts as the trust boundary by design — it is already a user-curated allowlist. Anything the user wants externally accessible gets wrapped in a skill; everything else stays internal. No separate security configuration required.
Describe alternatives you've considered
Exposing raw Obsidian commands via MCP was considered but explicitly ruled out. ObsidiBot already publishes every Obsidian command — including third-party plugins — which creates a powerful but unbounded surface. Skills-only keeps the external API intentional and user-controlled.
Use Case
Additional Context
This builds naturally on the existing skills infrastructure. The community marketplace (#62, watch system) and scoped permission model (#61) would both benefit from a well-defined external invocation surface.
Raw Obsidian command exposure is explicitly out of scope. Users who want to expose a specific command externally should wrap it in a skill first.
Implementation Suggestions
The implementation surface is narrow:
The heavy lifting (skill parsing, parameter interpolation, execution) already exists. This is primarily an MCP transport layer over existing functionality.