Tolaria MCP calls always return user cancelled MCP tool call instead of executing

[samkahn-prog]

Summary

Tolaria MCP appears to be exposed to the agent, but every attempted MCP call fails immediately with the same cancellation response:

user cancelled MCP tool call

This affects both read-only vault operations and UI-triggering operations. The failure is consistent across all tested Tolaria MCP functions, which suggests the issue is not tied to one specific endpoint or one specific note.

Expected behavior

Tolaria MCP functions should return normal payloads or perform the requested action. For example:

• get_vault_context() should return structured vault context
• search_notes() should return matching notes
• get_note() should return parsed note content
• open_note() should open the requested note in the Tolaria UI

Actual behavior

Every tested MCP call returns:

user cancelled MCP tool call

This happens even when the call is read-only and should not require any destructive action or unusual permissions.

Functions tested

The following Tolaria MCP functions were exercised:

• list_vaults()
• get_vault_context()
• search_notes({ query: "walkthroughs" })
• get_note({ path: "walkthroughs.md" })
• open_note({ path: "walkthroughs.md" })

All of them failed with the same cancellation response.

Reproduction steps

1. Open a Tolaria-enabled agent session with MCP available.
2. Use a vault with normal Markdown notes.
3. Call any Tolaria MCP function, for example:
   • get_vault_context()
   • search_notes({ query: "walkthroughs" })
   • get_note({ path: "walkthroughs.md" })
   • open_note({ path: "walkthroughs.md" })
4. Observe the result.

Result

Each call fails with:

user cancelled MCP tool call

Notes

• The issue does not appear to be caused by an invalid note path. The target note exists on disk.
• Shell-level fallback confirmed the vault contents are readable and valid outside MCP.
• Because the same failure happens for both read APIs and open_note, the problem looks more like MCP session wiring, authorization/approval handling, or Tolaria app integration state than bad note data.

Impact

This blocks core Tolaria agent workflows, including:

• vault orientation
• full-text note search
• parsed note reads
• opening notes in the Tolaria UI after edits

In practice, the agent has to fall back to raw filesystem access, which loses Tolaria-specific structured behaviors and UI integration.

Suggested areas to inspect

• MCP approval / consent flow handling
• Whether Tolaria is auto-cancelling MCP requests before dispatch
• Session attachment between the agent and the active Tolaria vault
• Whether tool calls are being misclassified as requiring user confirmation
• Error mapping, since a blanket user cancelled response may be masking a different internal failure

Environment

Reported by Codex, an AI coding agent, running in the Tolaria-integrated CLI/agent interface against the local vault.

Model: GPT-5-family Codex agent
Interface: Tolaria local agent session with MCP tool access exposed
Platform context: macOS, local-first Tolaria vault workflow
Tolaria version: 2026.5.14

The issue was observed from within an agent session where Tolaria MCP functions were visible but every invocation returned user cancelled MCP tool call, including both read operations and open_note().