MCP Tools v0.2.27 incompatible with Local REST API v3.4.x — missing apiExtensions and certificateInfo in root response

[rhm2k]

Description

MCP Tools v0.2.27 fails to connect when used with Local REST API v3.4.3. The MCP Server validates the root endpoint (GET /) response and requires apiExtensions (array) and certificateInfo (object) fields to be present. These fields are included in the authenticated response from Local REST API v3.2.0 but are absent from v3.4.3's response.

(This could alternatively be a Local REST API issue if the root endpoint response change in v3.4.x was unintentional — see coddingtonbear/obsidian-local-rest-api.)

Steps to Reproduce

1. Install MCP Tools v0.2.27 in a vault
2. Install Local REST API v3.4.3 in the same vault
3. Configure Claude Desktop and restart
4. Attempt any MCP tool call

Expected Behavior

MCP Tools should work with the current version of Local REST API.

Actual Behavior

Every MCP tool call fails with:

MCP error -32603: GET / 200: apiExtensions must be an array (was missing)
certificateInfo must be an object (was missing)

Verification

Browser-based testing of the root endpoint confirms the difference:

Local REST API v3.2.0 authenticated response includes:

{
  "authenticated": true,
  "certificateInfo": { "validityDays": 364.77, "regenerateRecommended": false },
  "apiExtensions": [{ "id": "mcp-tools", ... }]
}

Local REST API v3.4.3 authenticated response does NOT include certificateInfo or apiExtensions fields.

Workaround

Downgrade Local REST API to v3.2.0 by replacing the plugin files (except data.json) with those from a working v3.2.0 installation.

Environment

• macOS
• Obsidian v1.11.7
• MCP Tools v0.2.27
• Local REST API v3.4.3 (broken) / v3.2.0 (working)
• Claude Desktop (Cowork mode)

[coddingtonbear]

I'm afraid the difference you're noting isn't rooted in any changes that occurred in Obsidian Local REST API between those versions (there weren't any) -- what you're seeing is just that you aren't authenticated.

If you're authenticated (i.e. you provide a valid bearer token), additional fields are returned to you in the response you receive when you GET to / -- those extra fields are the very ones you're not seeing in your response.