Tools & MCP
Your business objects, as governed tools for any AI.
Most companies wire AI to their data with handwritten glue that bypasses every control they have. ObjectStack generates governed tools from the ontology instead — Agent-operable is one of its four promises: the objects your definition declares and the actions it exposes become MCP tools, called under the signed-in user’s own permissions, approvals, and audit, whatever your model — Claude, Cursor, or something fully local. The MCP server ships in the open framework and is on by default in every edition; ObjectOS is ObjectOS Community, Cloud and Enterprise, and runs the same server.
- Auto-wired
- Query, schema, and action tools register themselves from your objects
- Any client
- Claude, Cursor, local models, or your own agent runtime
- User-scoped
- Row and field rules enforced on every tool call
Connect in minutes
Point any MCP client at your runtime.
Every ObjectStack deployment already serves MCP at /api/v1/mcp — on by default, nothing to install. One command, or one entry in your client configuration, connects the model to your governed objects. From there, every query and action is checked against the signed-in user’s permissions.
# Claude Code — the first tool call opens a browser login
claude mcp add --transport http my-app \
https://your-deployment.example.com/api/v1/mcp
# Any MCP client (.mcp.json), with an API key
{
"mcpServers": {
"objectstack": {
"type": "http",
"url": "https://your-deployment.example.com/api/v1/mcp",
"headers": { "x-api-key": "osk_..." }
}
}
}What the AI gets
Tools that already know your business
Because the tools derive from the ontology that defines the application, the AI sees real objects, real relationships, and real actions — not a raw database dump.
Query business objects
Search, filter, and traverse relationships over customers, orders, cases — whatever your definitions model — with the schema as context.
Run exposed actions
Actions that metadata explicitly exposes become callable tools: assign a case, start a flow, generate a summary — nothing implicit.
Inspect the schema
Agents can read object and field definitions to plan work, scoped to what the signed-in user is allowed to see.
Same rules as people
A tool call is just another governed request
The MCP server sits inside the runtime, not beside it — so there is no side door. Every call goes through the same enforcement path as a click in the UI.
Signed-in identity
Tool calls carry the user’s identity. Row-level and field-level rules apply exactly as they would in a screen or API request.
Approval-gated writes
Actions that require sign-off queue for approval when called by an AI, the same as when called by a person.
Every call audited
Tool invocations land in the audit log with who, what, and when — appearing in the audit viewer beside human activity, with the same filters and the same old → new diffs.
Decision surface
What changes, who reviews it, what runs
| Tool call | What the AI sends | What the runtime checks |
|---|---|---|
| Query records | Filters over business objects | Row and field rules for the signed-in user |
| Run an action | A named action with parameters | Permission, approval requirement, parameter validation |
| Inspect schema | A metadata read | Only objects and fields the user may see |
| Update a record | Field changes on one record | Field-level rights, validations, audit entry |
FAQ
Frequently asked questions
Is the MCP server in the open-source ObjectStack?
Yes — it is the core of the open-source ObjectStack AI story. @objectstack/mcp ships with ObjectStack, so you can connect Claude, Cursor, or a fully local model to your governed objects without a cloud subscription.
Do we have to expose everything to the AI?
No. Business objects are bridged automatically while system objects stay excluded by default, actions become tools only when metadata exposes them, and every call is still filtered by the caller’s row- and field-level permissions.
Next pages