ai agents (mcp)

point claude, cursor or any mcp client at a briven database — and know exactly what it can and cannot do.

the config to paste

Briven speaks the Model Context Protocol over plain HTTP. Create an API key on the api keys page, then add this to your client's MCP settings.

json

{
  "mcpServers": {
    "briven": {
      "type": "http",
      "url": "https://briven.tech/api/mcp",
      "headers": {
        "Authorization": "Bearer brk_your_key_here"
      }
    }
  }
}

That is the whole setup. There is nothing to install and no process to keep running — the server is the same one that serves the rest of briven.

use a read-only key first. A read-only key gets every reading tool and branching, and is refused every write. That is a good place to start with a database you care about — you can widen it later, and you cannot un-run a change.

what the agent gets

list_databasesread
the databases the key can reach.
list_tablesread
tables in a database. briven's own bookkeeping is hidden.
describe_tableread
columns, types, nullability, defaults and the primary key.
queryread
one read-only statement. select, with, explain, show — nothing else, whatever the key allows.
write_querywrite
one statement that changes data or schema. refused outright on a read-only key.
list_branchesread
the copies of a database, and when each was taken.
create_branchcreates a database
a copy to experiment on. counts against your branch limit.
list_restore_pointsread
the moments a database can be taken back to, and whether each is still reachable.

what it deliberately does not get

These are all real briven features. You can do every one of them from the dashboard, the management api or the cli. None of them is offered to a model, and the reasoning is the same each time: an assistant acts on an instruction that may have been ambiguous, at speed, and it reports success either way.

delete a databaseabsent
the one irreversible act in the product. "clean up the old test databases" is a sentence a person understands with context a model does not have. there is no wording that makes this safe.
reveal a connection stringabsent
would put a live credential into a model's context, and from there into a transcript. once it is in the transcript it is in the transcript.
restore a databaseabsent
recoverable, which is exactly why it is tempting. an agent that restores "to be safe" costs you a database you did not ask for and disconnects the one you were using. reading restore points is offered; acting on them is not.

The rule we apply: a tool is offered only if the worst reading of an ambiguous instruction is still something you can undo in one click. Branching qualifies — the worst case is a spare database. Deleting does not.

the safe way to let it try things

Ask the assistant to branch first. A branch is a real, separate database taken at this moment — it can make whatever mess it likes there, and your original is untouched.

a safe experiment

you:   this migration might be wrong. try it somewhere safe first.
agent: create_branch { name: "before-price-migration" }
       write_query   { database: "before-price-migration", sql: "ALTER TABLE …" }
       query         { database: "before-price-migration", sql: "SELECT …" }
       "it worked on the copy. 412 rows changed. want me to describe the diff?"

branches are not free. A branch is a database and counts against your plan's branch limit, and taking one briefly disconnects the original's open connections. The agent cannot delete it afterwards — that is deliberate, and it means you decide what to keep.

you can see everything it did

Every tool call writes an audit row — the successes and the refusals — naming the tool and the key that ran it, never a person. An agent's work shows up in your history marked as a machine, so you can tell it apart from your own edits afterwards.