Omazy runs an MCP server. Point an AI client at it and that client can work on one of your businesses directly: read the agent’s instructions, search the knowledge base, add products, change the widget.
https://mw.omazy.ai/api/v1/mcpThis is for managing a business. It is not the tooling your agent uses to answer customers, which is configured per agent and lives elsewhere.
One connection, one business
Section titled “One connection, one business”A connection is scoped to a single business and to your role in it. Sign in as a manager of one workspace and the connection can reach that workspace and nothing else, no matter what the client asks for. Belong to four businesses and you make four connections, each approved separately.
The scope is decided at approval time from your actual membership, so a client cannot widen it by asking.
Two ways to connect
Section titled “Two ways to connect”Hosted clients: approve in the browser
Section titled “Hosted clients: approve in the browser”Claude and other hosted clients have nowhere to paste a token, so they use OAuth. Add the URL above as a custom connector and the client does the rest:
- It discovers the server and registers itself.
- You land on an approval screen in your Omazy console.
- You pick which business and how much access.
- The client is handed a key scoped to that choice.
You stay signed in to Omazy for the approval, which is what proves who you are. Nothing is issued if you cancel.
Local clients: mint a token
Section titled “Local clients: mint a token”Claude Code, a script or a CLI can hold a bearer token. Mint one in the console under Settings → Connected AI, then:
claude mcp add --transport http omazy https://mw.omazy.ai/api/v1/mcp \ --header "Authorization: Bearer <token>"The token is shown once and stored hashed, so it cannot be recovered later. It lasts 7 days by default and 90 at the most. Mint a new one rather than trying to extend it.
Read-only or read-write
Section titled “Read-only or read-write”You choose this when you approve the connection, and it is worth choosing deliberately.
| Choice | What the client can do |
|---|---|
| Read only | Look at the business, read the agent and its Brief, search knowledge, view the widget config. Cannot change anything. |
| Read and write | Everything above, plus edit the agent, publish knowledge, add products, change the widget. Capped at your own role. |
Read-only is enforced two ways: the key is issued at member role, and it carries an allowlist naming exactly the tools it may call. A tool missing from that list is simply unavailable, so a mistake there removes access rather than granting it.
“Read and write” never exceeds you. If you are a manager, the connection is a manager. It cannot create workspaces or touch billing on your behalf.
What a connection can reach
Section titled “What a connection can reach”| Area | Read | Write |
|---|---|---|
| Business and apps | Yes | Create a business (account scope) |
| Agent identity and prompt | Yes | Through the Brief |
| Agent Brief, with version history | Yes | Edit, reorder, restore, publish |
| Answer suggestion pills | Yes | Replace the rule list |
| Knowledge base | Read and search | Add documents |
| Help centre and catalog | Yes | Add articles and products |
| Widget | List and read config | Change config, publish, create |
Every tool, with its arguments and the role it needs, is in the MCP server reference.
Changing how the agent answers
Section titled “Changing how the agent answers”One thing to know before you let a client edit your agent: on an agent that uses the Brief, the system prompt is generated, not stored. Publishing the Brief composes the enabled blocks and overwrites it.
So a client that writes the prompt directly produces a change that works for a while and then vanishes the next time anyone publishes from the console, with no record of what it replaced. The server refuses that write and says so, naming the tools to use instead. Edit the Brief, then publish.
Managing connections
Section titled “Managing connections”Settings → Connected AI in the console lists every connection: which client, read-only or read-write, when it was last used, how many calls it has made, and a button to revoke it.
Revoking is immediate. For a connection made through the browser it also kills the refresh chain, so the client cannot quietly reconnect with a token it still holds.
The same page shows recent tool calls with timing and outcome. Arguments are never recorded, so the log is safe to read in front of other people.
When it does not work
Section titled “When it does not work”The client connects, then reports the credentials were rejected. Sign-in worked and a key was issued, but the calls that follow never arrive. Check whether something between the client and the server is filtering AI-agent traffic: a bot or AI-scraper rule at your CDN or proxy will drop those calls while leaving the sign-in steps untouched, because they are made by different clients. The console tells you which side is at fault: a connection sitting at 0 calls and never used was never reached.
Every call fails with an authorization error. The key has expired. Minted tokens last 7 days by default. Reconnect or mint a new one.
A tool says it needs a different role. The connection carries your workspace role. Ask an owner or manager to make the connection instead, or to raise your role.
A write says the connection is not scoped for it. The connection was approved read-only. Reconnect and choose read and write.