What it does
avo-mcp_serverLet Claude, Cursor or ChatGPT work in your admin. MCP gives your Rails app a Model Context Protocol server inside your Avo app, so an AI assistant can discover your resources, search and inspect records, create and update data, and run your Avo actions, all from a chat prompt. Ask "find the users with admin in their email" or "create an article titled Getting Started by Sarah Chen" and the model calls the right tools against your real resources.
It exposes ten tools (from list_resources and
search_records through create_record,
run_action, and delete_record) over HTTPS at
/avo/mcp. An admin approves each client on a consent screen and
picks what it may do, and from then on the client acts as that admin: every
call goes through the same policies as the UI, so what a role cannot see in
Avo it cannot read or change over MCP either. The tool layer and its
guardrails are already built and vetted; you add a gem instead of
generating them.
See it in action
What you get
-
Ten MCP tools:
list_resources,list_records,count_records,show_record,search_records,create_record,update_record,delete_record,list_actions, andrun_action - A remote server over HTTPS with OAuth: Claude Code, Codex CLI, Cursor, Amp, VS Code, and ChatGPT in developer mode connect without a pasted token
- Grant each connection Read, Read and write, or Run actions, narrowed per resource, and change or revoke it from the admin at any time
- Every call runs through the connecting admin's own Avo policies and field visibility, re-checked on each request, so the model can only read or change what that admin may
-
Add tools of your own with
config.mcp_server.extra_tools - Runs your custom Avo actions on a record or a batch, the same actions you already defined in the admin
-
Structured error types (
invalid_params,not_found,not_authorized,validation_error) so the model gets a clear answer back
Why it pays off
- An AI bridge to your admin is mostly the tool layer and its guardrails: ship that this week instead of speccing it over a sprint.
- One authorization layer, every surface: the policy that scopes records, hides attributes, and gates actions in the UI binds the model too, so there is no second access-control layer to write for agents.
- Every Avo release makes it better: the MCP server, its OAuth flow, and the exposed tools stay aligned with your resources and keep working through upgrades, and fixes ship to every app at once.
- The tool layer is built for many apps and reviewed by people, so your agents work inside an admin that has already been vetted, in this app and the next.
Questions
How do I add an MCP server to a Rails app?
On Avo 4.2 or newer, add the avo-mcp_server gem, run its generator, and mount the routes; the docs walk through each step. The server answers at /avo/mcp and needs your app reachable over public HTTPS. Your license needs the MCP Server and Authorization add-ons: without Authorization the server refuses to start rather than run without policy checks.
Which AI clients can connect?
Claude Code, Codex CLI, Cursor, Amp and VS Code, plus ChatGPT with developer mode on. Any client that supports remote MCP servers with OAuth should work. There is no stdio transport: clients connect over HTTPS and sign in through your admin.
Can an AI agent see or change data it shouldn't?
Every call passes two checks: the access an admin granted the connection (Read, Read and write, or Run actions, per resource), then that admin's own Avo policies, re-checked on each request. Hidden fields stay hidden and credential-like columns are refused. With audit logging, every change an agent makes is recorded under the admin who connected it.