The server exposes a single tool 'mcp-obsidian' that is dynamically loaded from an external MCP server. The tool definition is inferred rather than explicitly registered in the source code, only a string name and generic description are visible in Jarvis/MCP.cs. No input schema, parameter descriptions, or output schema are defined or visible. The description 'MCP tools dynamically loaded from the mcp-obsidian server for Obsidian vault operations' is generic and does not explain what the tool does, when to use it, or what it returns.

• Explicitly register the mcp-obsidian tool in Jarvis/MCP.cs with a full schema: name, description (50-200 chars), input parameters with types and descriptions, and documented output fields. Do not rely on dynamic loading to hide the schema.
• Replace the generic description with a specific, actionable one: 'Search, read, and manage notes in an Obsidian vault. Use this to retrieve note content, list vault structure, or update notes. Returns note metadata and content as markdown.'
• Document all input parameters accepted by mcp-obsidian (e.g., query, vault_path, note_id, operation) with types (string, enum, number), descriptions, and constraints. Use enums for operation types (read, search, list, update).
• Document the output schema: what fields are returned (note_id, title, content, path, created_at, updated_at), their types, and whether results are paginated. Include guidance on chaining IDs for follow-up calls.
• Add error handling: catch failures from the external mcp-obsidian server and return actionable errors. E.g., 'Note not found. Try search_notes() with a partial title.' instead of a raw exception.