Control MASAIC from your coding agent

MASAIC runs an MCP server. MCP (Model Context Protocol) is a standard way for an AI assistant to use outside tools — so once your coding agent is connected, it can read and change your workspace because you asked it to, in plain language.

This is useful when you know what you want but not where it is in the console, when a change touches a dozen agents at once, or when you would rather describe a change than click it.

What you need

Connect it

Sign in once, then wire up your assistant:

masaic login
masaic mcp install claude-code

Restart the assistant and it will have MASAIC available. To check:

masaic mcp status

That prints which assistants are wired up and whether MASAIC actually answers — use it before you start blaming the assistant.

Pick your assistant

masaic mcp install takes the name of the assistant, and each one keeps its settings in a different place:

The project-scoped claude-code form writes a file in your repository, so your whole team gets the same connection when they check it out. The others are per-user.

Want to see the change before it happens?

masaic mcp install cursor --dry-run

That prints the resulting config and writes nothing. Adding MASAIC never disturbs the other MCP servers already in those files.

To disconnect:

masaic mcp uninstall cursor

No token in the config file

Worth knowing, because it is the usual worry with MCP setups: the config file gets no credential. What it gets is an instruction to launch the CLI, which resolves — and refreshes — your sign-in per message from the store masaic login wrote.

So a config file you commit to your repository carries no secret, and your teammates each authenticate as themselves.

What you can ask for

Once connected, the assistant can work with:

• Agents — list them with their versions, create one, change one (which publishes a new version), read its voice, runtime, and guardrail settings, delete one.
• Skills — list, create, delete.
• Prompts and resources — the instruction and knowledge content your agents use.
• Test cases and runs — list and create test cases, start a run, then read back its status, scores, and transcripts.
• Mock users and personas — the synthetic customers your tests talk to, including their tone, language, and emotional state.
• Automation tasks — list, create, change, pause, resume, run one immediately, and read the run history.
• Analytics — conversations, token usage, tool calls, and latency for the workspace or one agent.

Things that read well as questions:

• "List the agents in this project and say which have no test cases."
• "Create a test persona who is impatient and speaks German, then run the billing agent's test suite against it."
• "Which agent used the most tokens last week?"
• "Pause every automation task that posts to Slack."

Because the assistant does the reading, you do not need to know which console screen holds the answer.

Before you let it change things

The assistant acts as you, with your permissions — not a reduced set. Two habits worth keeping:

1. Start in a non-production project or environment. "Tidy up the unused agents" is a real instruction with real consequences (Environments).
2. Keep the production step manual. Let the assistant prepare and test a change; promote it through your normal release process (Safe rollouts).

Destructive operations ask for confirmation, but the reliable protection is the project you pointed it at.

If it does not work

Related

• The masaic CLI — the same operations as commands, plus YAML you can keep in git.
• MCP servers and tools — the other direction: giving your agents tools to call.
• Testing and release — the test suites an assistant can run for you.

← Ways to control MASAIC · The masaic CLI →