AI Assistants (MCP)

Every hosted API speaks MCP — the Model Context Protocol, the standard way an AI assistant reaches a tool outside itself. Connect one to your app and it works with your data the way a colleague with your account would: look something up, answer a question about it, add a record, tidy a list.

Audience: people connecting an assistant to their app — not the assistant itself.

There is nothing to install, deploy or switch on. It comes with the API, at an address you already know.

The address

Your app's own URL with /mcp on the end:

https://<app>.softeria.app/mcp

Any hostname your app already answers on works the same way — your own domain, or one under your company's:

https://app.my-company.com/mcp
https://<alias>.apps.my-company.com/mcp

Use whichever address you would normally open the app at.

Connecting

The steps are the same in any MCP-capable client — Claude's desktop and web apps, Claude cowork, and others:

1. Open the client's connector settings. In Claude: Settings → Connectors → Add custom connector.
2. Paste your app's /mcp address.
3. Your app's own login page opens. Sign in the way you always do — same account, same buttons.
4. Approve the connection.

That's the whole setup. Ask for something from your app in the conversation and the assistant goes and gets it.

Sign-in may open on a different hostname

If your app also lives on your own domain, you may be sent there to sign in even though you pasted a softeria.app address. That is deliberate: your identity provider only accepts the hostname registered with it. Finish signing in there and the connection completes normally.

What the assistant can reach

Your schema, as operations:

In your API	What the assistant can do
Collections	Read, create, update, delete
Views	Read, create, update, delete
Queries	Read
Functions	Call
Collections linked from another API	Read

A view is not a read-only surface. Views are fully updatable here as everywhere else, so an assistant can write and delete through one exactly as it can through the collection underneath. If you want a read-only shape, use a query, or a role that only grants read.

Reading is the real thing rather than a stripped-down version — filtering, sorting, paging, picking properties, pulling in child records, and search where you have enabled it.

A real API adds up to five or six hundred operations, far more than an assistant can hold at once, so it is not handed a list of them. It searches for the operation it needs by name, reads that one's contract, and then runs it. The names follow your schema — query_orders, create_orders, call_sendReceipt — so what the assistant says it did lines up with what you named things in the portal.

It acts as you

Every call runs as the user who signed in. Roles, access rules and security policies apply exactly as they do everywhere else — no bypass, no admin mode, nothing reachable that you could not reach yourself in the app.

So when an assistant reports it is not allowed to see something, that is your account's access rather than a broken connection. The fix is wherever that access is decided — a role, an access rule, a security policy — not a reconnect.

The credential the client ends up holding is good for the MCP address and nothing else. It cannot be turned around and used as a general API key against the rest of your API.

Writes and deletes are real

Create, update and delete go through as ordinary writes — triggers fire, and a delete cannot be undone.

Your client cannot warn you which is which. Everything an assistant does reaches your app through one and the same operation, so the approval prompt looks identical whether it is about to list ten orders or delete one. That means "always allow", granted once during a harmless lookup, also approves every update and delete that follows. Approve them one at a time, and for work that should only ever read, sign in with an account whose role grants read access only.

Where it stops

• Very large results — roughly a megabyte of text is the ceiling. Past that the assistant is told to narrow the request rather than handed a truncated answer it might report as complete.
• Reading files back — blob contents do not come back through the connector. The assistant is told what the file is, its type and size, and no more: a file lives at its own address, which the connector's credential is not allowed to reach. Open it in the app instead. Writing a file is a different matter — a file small enough to fit in a record can be sent along with it.
• Long-running work — each request is answered on its own. There is no stream or session held open between them.

Clients that insist on registering

Most connectors, Claude's included, identify themselves without any setup on your side. A few other MCP clients will only connect after registering themselves with the server first.

That is off by default: registration is an unauthenticated write to your tenant, so it is not something to leave open without a reason. It can be turned on per API with the DynamicClientRegistration setting, and it is worth turning on only when a client you actually want fails without it.

See also

• Data Access (rat data) — the command-line route to the same data, and how to wrap it in a Claude skill
• Roles and Access Rules — what the signed-in user can reach
• Authentication — sign-in, identity providers, and service accounts
• Views and Queries — the filtered shapes an assistant works through; a view is writable, a query is not