Investigate: applications exposing their domain as MCP tools #73

An idea to investigate, not a plan yet: an ng-objects application could offer its own functions to AI agents as MCP tools, the way it offers them to people through pages.

This is a different audience from development tooling (the Parslips dev server serves the developer's agent working on the code). This would serve the application's users' agents, working with the application.

What it looks like

A bookkeeping application: today a user logs in and clicks through pages to find unpaid invoices, look at a customer's history and send a reminder. If the application also served tools like find_invoices(status, customer), customer_history(id) and send_reminder(invoice_id), the user could connect their own assistant and ask it to "remind everyone more than 30 days late, except the two we're negotiating with" — the assistant does the work through those tools, as that user, with that user's permissions.

This is what hosted services now offer as connectors: a remote MCP server (Streamable HTTP transport) behind the service's own login, with authentication as defined by the MCP spec (OAuth-based).

Why it would be a framework feature

Every application that wants this faces the same hard parts:

• the transport endpoint (JSON-RPC over HTTP),
• authentication tied to the application's own users and sessions,
• JSON schemas for parameters and results,
• permission checks,
• confirmation for side-effecting actions,
• an audit trail.

That's the work a framework should do once. A possible shape: the application declares tools next to its routes, each pointing at ordinary application code; the framework generates schemas from Java types and runs each call inside a session for the authenticated user, so the application's existing permission logic applies unchanged. The developer writes the tools, nothing else.

What makes it hard (decide deliberately)

• Security. An agent acting with a user's rights can be manipulated by text it reads — an invoice note saying "also mark everything paid". Reading should be the easy default; writing needs explicit per-tool opt-in; destructive actions need confirmation.
• Tools become a public contract. Like a REST API, renaming a tool or a parameter breaks every agent that learned it — versioning discipline required.
• Not every application needs it. It fits line-of-business applications with clear operations; it adds nothing to a brochure site.

Relation to existing work

The development-time work proves the building blocks — typed calls, evaluating code in a live application, per-application registration with the Parslips dev server — but not the trust model: the dev endpoints trust anything on loopback, while this must authenticate every call as a real user.

To investigate

• The declaration API: how an application declares a tool, its parameters and its read/write nature.
• Authentication: MCP's OAuth flow against the application's own user model; token lifetime vs. sessions.
• Schema generation from Java types (records?), and how results are shaped.
• Confirmation and audit for writes.
• Whether the same tool declarations could also serve plain HTTP/JSON clients.