Docs / AMS / Share and change / Build and govern Mindset from Claude

Build and govern Mindset from Claude

Connect Claude Code or another AI client to Mindset's administrators' MCP server, and build, test and govern agents from your own client.

After this page, you can do your admin work in Mindset from Claude Code, Cursor or another AI client. You ask Claude to add a step to the invoice exceptions agent's script, test it, and show you who changed its connections last week, and Claude does it through the same service functions AMS uses.

What this is

Mindset runs a second MCP server for org admins, named mindset-admin. MCP is a standard way for an AI client to see what another system offers and call it. Through this server your client can author resources, manage agents and govern the org.

	Users' server	Administrators' server
Name in your client	`mindset`	`mindset-admin`
What it carries	Two tools: list the agents available to you, and call one	Building, testing, running and governing, below
Who can use it	Every member	Org admins only. Anyone else gets "not found"
Set up from	The Hub	Settings → Systems

For the users' server, see Use your agents from Claude and other AI clients.

Set it up

Open Settings → Systems. Under Connect an AI client, choose For administrators. It's selected when the screen opens.
Pick the tool you work in: Claude Code, Cursor, Copilot (VS Code), Claude Desktop or Claude.ai.
Copy the prompt and paste it into your client. For Claude Code, the prompt runs:
sh
```
claude mcp add --transport http --scope project mindset-admin https://<your Mindset host>/api/v1/orgs/<org>/envs/<environment>/mcp
```
It also adds a short "Using Mindset" note to the project's CLAUDE.md, so the agent knows what Mindset is next session.
Sign in. Adding the server doesn't open a browser. In Claude Code, run /mcp, pick mindset-admin and sign in with your Mindset account in the browser. There's no key to paste.
Check it works. Ask your client "list my Mindset agents".

The panel's footer shows how many admins have connected.

Environments and `envSlug`

The address names one environment. The panel prints the address for the environment chosen in the nav switcher, so switch first if you want a different one.

That environment is the default for every call. Each environment-scoped tool also takes an optional envSlug, which points that one call at another environment, for example to compare the invoice exceptions agent in Sandbox and Production. Org-level tools, such as members or retention, refuse an envSlug. Only an admin's signed-in connection can name a different environment. A session using an API key can't.

What you can do through it

Job	What the tools cover
Agents	Create, read, update, archive and delete agents, change their configuration, and manage their versions
Scripts, functions and widgets	Find curated examples, create and edit resources, test them, publish and unpublish, and activate an earlier version
Connections	Probe an endpoint, read an API description, store a credential, start an OAuth sign-in, and govern each operation (enable, disable, hide, admin-only, read or write)
Triggers and schedules	Read triggers, schedules, their runs and webhook deliveries
Testing	Behavior tests, experiments and test runs
Runs and conversations	Read and stop runs, start and read conversations, and call agents
Costs	Read what the org has spent on model calls, the same figures as Govern → Monitor → Cost
Audit	Query the audit trail, read one record, and draw charts
The org	Members, auto-grouping, environments, retention, and the personal data policy

Your client can also ask Mindset for guidance. get_information returns the topic index, and the note it adds to CLAUDE.md tells the agent to read it before authoring anything.

Everything is checked against your real admin permissions on every call. If your client says it did something Mindset can't do, it didn't happen.

Credentials never go through the model

No tool takes a secret value. When a connection needs an API key:

Your client calls request_capture. It gets back a reference to the secret and a capture URL.
You open the URL. The page reads Paste your followed by the credential's name, and says "This goes straight to the encrypted vault. The AI agent never sees it."
Paste the value and click Save. Only an admin of the org can complete it.

Your client then uses the reference. The value is stored on the server and never comes back to the client. Never paste a credential into the conversation, even if asked. For an OAuth sign-in, authorize_connection returns a link for you to open in the same way.

The go-ahead for writes

A test run that would write to a connected system is refused the first time. Your client gets the list of everything the run will read and write, and has to tell you in plain words. When you say go, it calls again with your instruction quoted. A run of an agent version that isn't active works the same way. See Test before it goes live.

Approving a write operation for real use stays a person's act in AMS. Your client can enable a read operation, but a write operation waiting for approval stays waiting, and no tool argument gets round it. See Approve what an agent can do.

What can go wrong

"Not found" when your client connects. You aren't an org admin in that org. Members use the users' server.
Your client asks you to paste a key. Don't. Ask it to use request_capture and open the capture URL yourself.
A capture link says it's no longer valid. Ask your client to start a new capture.
An agent or resource your client deleted is gone. Deleting can't be undone. Archiving an agent takes it out of use without deleting it.
Your client changed the wrong environment. Check the address in your MCP settings and any envSlug it passed.
Enabling a write operation came back un-enabled. It's waiting for a person to approve it in AMS.