What MCP actually changes about form operations

The Model Context Protocol is easy to describe and easy to under-sell. It's a standard way for a model-driven client to discover what a system can do and then do it. Say it that way and it sounds like an API with extra steps.

The difference shows up in who does the integration work — and how often.

The N-by-M problem

With a conventional API, every agent that wants to work with your system needs an adapter: someone reads the docs, decides which endpoints matter, writes the tool definitions, maps the schemas, and maintains that mapping as both sides change. Do that for three agents against four systems and you're maintaining twelve adapters, each of which rots independently.

MCP inverts the direction. The system describes its own capabilities — tools, resources, schemas — in a form any compliant client can read at connection time. The client doesn't need to be taught your API. It asks.

The practical result is that adding a new agent costs approximately nothing, and changing your system's capabilities doesn't require updating every consumer's hand-written mapping. The description is the contract, and it ships with the system.

What "form operations over MCP" means concretely

Mandda runs a native MCP server at /mcp, over the same domain the interface and the REST API use. A connected agent can:

• Discover forms and their structure — fields, types, validation, and the version a given structure belongs to. No scraping a rendered page, no stale field map.
• Create and modify forms programmatically, which is what makes "spin up an intake for this campaign" a sentence someone can say rather than a ticket someone files.
• Read responses as structured data, with the form version each was captured under attached, so answers stay interpretable after the form changes.
• Write submission metadata — state, owner, priority, decision — onto the same records the team works in the interface.

That last one is the load-bearing capability. Reading is a reporting feature. Writing to shared operational state is what lets an agent take real work off a queue.

Authorization is the part that decides whether this is usable

An agent surface that requires a global key is a non-starter for anything multi-tenant. The blast radius of a leaked credential is the entire platform, and there's no honest way to answer "what can this agent see."

Mandda binds agent authorization to the workspace through OAuth, with scopes. An agent connected to a workspace is scoped exactly like a member of it — same tenancy boundaries, same role-based limits, same authorization path the interface uses. There is no privileged bypass, which means enabling an agent is a decision you can make per workspace and reason about afterwards.

This is less exciting than the capability list and considerably more important. Most "AI integration" projects die at the security review, and they die because the integration was built as an exception to the permission model rather than an expression of it.

What it doesn't do

MCP doesn't make an agent correct. It doesn't supply judgment, and it doesn't relieve you of designing what should be automated versus reviewed.

It also doesn't fix a domain model that has nowhere to put operational state. If submissions are rows of answers with no structured status, owner, or decision, then an agent connected over MCP can read them and little else. The protocol exposes the domain you have; it doesn't invent one. Everything useful an agent does here depends on submissions being modelled as records with writable operational state — MCP is the access path, not the substance.

A reasonable first step

Don't start by handing an agent the queue. Start with a task that's mechanical, verifiable, and reversible: classification against a fixed category set, or enrichment from a system the agent can already reach.

Let it write its output to the record. Watch it against what your team would have done. The work is visible in the same view humans use, on the same object, so evaluating it costs nothing extra — and expanding its scope, when the results justify it, is a configuration change rather than another integration project.

That's the shift worth naming. Not that agents can now touch your forms, but that the cost of letting them do a little more, or a little less, stops being a rewrite.