> ## Documentation Index
> Fetch the complete documentation index at: https://apidoc.ovrsea.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Introduction
> The three ways an AI agent can reach your OVRSEA account
Your OVRSEA data is reachable by software in three ways. They differ in who is driving, how the
caller signs in, and — most importantly — who is accountable for a write.
## Pick the one that matches who is driving
Your own code, on your own schedule. Predictable payloads, your error handling, your retries.
Your AI assistant — Claude, ChatGPT, Copilot, Cursor, Mistral — querying OVRSEA in natural
language, on behalf of the person using it.
Your team, inside Hermès. Nothing to install and nothing to build.
## How they differ
| | REST API | MCP server | Ask Zach |
| -------------------- | --------------------------------------- | ----------------------------------------- | -------------------------------------------- |
| Driven by | your code | your AI assistant | a person, in Hermès |
| Sign-in | API token from the API Integration page | OAuth, with the user's own OVRSEA account | already signed in to Hermès |
| Identity of a call | the token's account | the signed-in user | the signed-in user |
| Reads | the endpoints in **API Reference** | read tools | anything that user can already see |
| Writes | purchase orders only | most of the agent actions | the [agent actions](/ai/agent-actions) |
| Who approves a write | nobody — your code is accountable | the assistant, guided by tool annotations | the person, on a card or in the conversation |
Every channel resolves permissions server-side against the account that signed in, so an agent
works inside the same authorisation as the person it acts for — the same checks the equivalent
Hermès screen runs, not a separate agent-only rule set.
## Who approves a write, precisely
This is the part worth reading twice, because the answer is genuinely different per channel.
**REST API.** There is no approval step. A call with a valid token performs the write immediately.
Your code is the control. Purchase orders are the only thing it can write.
**MCP server.** Every tool is published with the standard MCP annotations — `readOnlyHint`,
`destructiveHint`, `idempotentHint` — so an assistant can tell a read from a write. **We publish
those signals, but we do not control how your assistant acts on them.** Most assistants ask the
user before running a tool that is not read-only; that behaviour belongs to the assistant, not to
OVRSEA.
Do not read `destructiveHint` as "everything you cannot undo": it marks the clearest cases, and
declining a quotation is not among them even though its prices do not come back. If you are wiring
the MCP server into something unattended, gate on the action, not only on the flag.
**Ask Zach.** Zach states what it is about to change before changing it, and waits for the person
to agree — on a card for the most common actions, in the conversation for the rest.
[Confirming a change](/ai/ask-zach) describes what that does and does not guarantee.
## Where to go next
The endpoint, how sign-in works, and what your assistant will be able to do.
The complete, generated list of what an agent can do on an account.