Hi Frank,
On the Tcl API and permissions: we've actually been running a Tcl-based API layer in production with multiple clients for our SPA for several years now. We've extended the ]po[ namespace with additional wrapper procs for several modules — timesheet tracking, for example — specifically to give our SPA clean API entry points with validation and permission handling. The Tcl layer gives us access to the full business logic (validation, side effects, audit calls) that the REST endpoints sometimes bypass or duplicate. It handles permission checking at the application level before executing business logic, so it's not operating with superuser rights in practice. That said, I realize my response was written from the perspective of our extended codebase, which has additional features beyond the main ]po[ distribution. Your REST API approach with built-in permissions is a perfectly valid starting point, especially since it's already there and working.
The more interesting question is probably: regardless of which API layer you expose through MCP, how do you handle the permission delegation? You mentioned wanting agents to work with the respective user's permissions — that's exactly right, and it's where something like OAuth token scoping or a principal-user-id passed through the agent layer becomes important. The agent authenticates as itself but acts on behalf of a specific user, and the API layer enforces that user's permission set. We solved this in our Tcl layer but the same pattern would work on top of your REST API.
On the iteration point — absolutely, customer value first. What I meant is more pragmatic: once you have the read-only MCP server running, you'll quickly see which write operations users actually ask the agent to perform. That usage data tells you what to build next, rather than guessing upfront.
Cheers,
Malte
