Loading ToolBench
MCP server for Obsidian knowledge management workflow with skills for note triaging, promotion, synthesis, and vault health feedback
This server presents a fundamental structural problem: tool definitions cannot be located or verified in the source code. The repository appears to organize 'skills' as directory structures with validators (bash scripts), but no explicit MCP tool registration, schemas, or parameter definitions are visible. The 7 tools listed (inbox-triage, connection-review, note-promotion, weekly-synthesis, vault-health-feedback, obsidian-mcp, opencode-context-maintenance) are inferred from directory names and SKILL.md files, not from machine-readable tool registration. The descriptions provided appear to come from the SKILL.md frontmatter ('Skill that triages inbox items...') rather than from MCP tool schemas. This is a pre-MCP or non-MCP implementation masquerading as an MCP server.
Skill that reviews connections between notes with scope constraint of max 15 primary notes
Skill that triages inbox items with synthesis markers detection and batch size constraints
Skill that evaluates and promotes notes with explicit decision output and integration target requirements
Core MCP integration skill with API safety checks preventing use of forbidden APIs (obsidian_patch_note, obsidian_append_to_note)
Skill that maintains opencode context with restrictions on config file modifications
Skill that provides health recommendations with max 3 recommendations and layered findings order
Skill that synthesizes weekly insights with exactly-one constraints for action and question fields
NO VISIBLE MCP TOOL SCHEMAS. The repository contains no JSON Schema definitions, input parameter schemas, or output schemas for any of the 7 tools. Tool definitions appear inferred from directory names and SKILL.md files, not from explicit MCP registration.
DESCRIPTIONS LACK ACTIONABLE DETAIL. All tool descriptions are generic summaries of 'skill that [does X] with [constraint Y]'. None answer: What does it do? When should the LLM call it instead of similar tools? What does it return? Required description length: 50-200 chars with actionable guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 17 | 2026-07-28+ | v2 |
TOOL NAMES LACK ACTION VERBS. Names like 'inbox-triage', 'connection-review', 'note-promotion', 'weekly-synthesis' are noun-based or gerunds, not verb_noun patterns. LLMs expect: triage_inbox, review_connections, promote_note, synthesize_weekly. Only 40-50% of the baseline verb-first naming convention met.
PARAMETER DOCUMENTATION ABSENT. No visible parameter descriptions, types, enums, or constraints for any tool. The validation scripts check batch sizes (max 20 for inbox-triage), scope constraints (max 15 for connection-review), and decision requirements (note-promotion), but these constraints are not exposed in tool parameter definitions.
OUTPUT SCHEMAS NOT DOCUMENTED. No machine-readable specification of what each tool returns. Validation scripts enforce post-execution constraints (e.g., 'connection-review must not produce synthesis markers', 'promoted notes must have at least 2 integration targets'), but these are runtime checks, not schema-declared contracts for LLM planning.
ERROR HANDLING NOT DOCUMENTED. Validators return pass/fail strings ('FAIL: Batch size exceeded', 'PASS: Triage output within constraints'), but tool definitions provide no error category guidance (retryable, user-fixable, fatal), recovery suggestions, or actionable error messages for LLMs.
SECURITY: obsidian-mcp TOOL USES FORBIDDEN APIS. The api-safety-check.sh script explicitly detects 'obsidian_patch_note' and 'obsidian_append_to_note' in execution logs as forbidden. If these APIs are integrated, they should be blocked at the tool interface level, not post-execution. Tool description must declare what permissions it requires and what it WILL NOT do.
TRANSPORT UNKNOWN. Repository does not reveal whether this is STDIO, HTTP+SSE, Streamable HTTP, or non-MCP RPC. Without transport visibility, protocol readiness cannot be assessed.