Skip to the page
orbstrataOpen the console
← All docs

Your AI client

The agent is an MCP server that Claude Desktop, Claude Code and Cursor start on your machine.

  • strata mcp --install claude-desktop (or claude-code, or cursor) adds the one entry that client needs. It shows the file and the entry first and asks; the entry holds no secret. Restart the client afterwards.
  • The client is offered the tools you have a connection for and your role may use. Each call is decided on the agent with your role and the workspace's rules, before it runs.
  • A result goes from the agent to the client on the same machine and nowhere else. It arrives fenced, naming the tool and the connection it came from, so the model reads it as data and never as instructions, and secrets in it are masked first.
  • A denial is an answer too: the reason, in a sentence, which the model can tell you.
  • Every call leaves a row in the agent's own audit: strata audit lists today's.

Through your workspace instead. An AI client that is not on the agent's machine reaches it through the service's gateway, the workspace's address followed by /mcp:

1. Run strata serve on a machine in your network that holds the connections (Agents shows it online). 2. For claude.ai or Claude Desktop, sign in instead of making a token: Connect claude.ai says how. For Claude Code, make an API token in Settings. The dialog that shows it once also shows the line for Claude Code, address and token filled in: claude mcp add --transport http <name> <address>/mcp --header "Authorization: Bearer ost_…". 3. Ask as you would ask the agent's own server.

The gateway offers the tools your workspace has a connection for and your role may use (a tool that writes also needs a token made with May also write, or an app let in with Let it act), and each description names the connections it can be called with, their tiers, and the rules that give a namespace or database a tier of its own. Name one in connection or source when there are several. Every call is decided twice with your role: at the gateway, so a denial costs nothing and is answered at once, and again on the agent, which never does more than the member who paired it may. The result comes back fenced and masked by the agent, passes through the service on its way to the client, and is never kept there. Each call leaves one row in the workspace's audit: who asked, the tool, the connection, the tier, the decision and how it went, with the arguments masked, never the result. An agent that is not connected, a call past its deadline and a denial are each an answer the model can read.

Ask it what you would ask a colleague who knows every database: what a table holds, how two tables join, what customer 9845's orders look like. It reads the map first (db_sources, db_tables, db_describe_table, map_search), then rows (db_sample, db_query), and never writes: every statement is one SELECT, run read-only, at most 500 rows a page. Ask it to tag the map, too: it reads the columns, profiles the ones it is unsure of, and proposes tags and join hints with its reasons (map_propose). A proposal changes nothing until a person applies it.

Personal data stays masked unless your role may see it. A column tagged personal or sensitive in the map is masked by its tag's shape before the agent answers (d••••@example.com, •••-••-9845, a name as initials, a date of birth as its year), unless your role holds personal data on that source's tier. Until someone tags a column, its name is enough: ssn, email, full_name, card_number and their like are masked from the first day. A role without personal data may not filter, join or sort on a sensitive column either, since a WHERE on an SSN tells whether a guess is right. The audit row says pii: shown when a call's values left whole.