# Connect an AI assistant

Connect Claude or any MCP client to one business, so it can read and change your agent, knowledge, catalog and widget.

Source: https://docs.omazy.ai/connect/mcp/

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/mcp
```

This 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

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

### 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:

1. It discovers the server and registers itself.
2. You land on an approval screen in your Omazy console.
3. You pick **which business** and **how much access**.
4. 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

Claude Code, a script or a CLI can hold a bearer token. Mint one in the console
under **Settings → Connected AI**, then:

```sh
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

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

| 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](/reference/platform/mcp-server/).

## 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

**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

**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.

:::caution[A connection acts as you]
Anything it does is attributed to you and audited under your name. Approve
read-only unless the client genuinely needs to change things, and revoke
connections you are no longer using.
:::