# Ondes PRO for web agencies and IT services firms

> Web agencies and IT firms: one MCP server per end client, API docs served to your AI on demand, and a test mode to integrate safely. Included in every plan.

Updated on 2026-10-21 · The Ondes PRO team · https://ondes.pro/en/integrations/mcp/industries/web-agencies

You build, maintain and extend websites and tools for several clients. Every client running Ondes PRO has its own instance, and so **its own MCP server**: your coding assistant connects with the permissions the client granted you, reads their API documentation on demand and tries its writes in test mode. Less searching, fewer round trips, and no real order created by mistake.

## One MCP server per end client: how does it work?

Every Ondes PRO client has an isolated instance at its own address: `galerie-ressac.ondes.pro`, `comptoir-des-marees.ondes.pro`… Its MCP server is that address followed by `/mcp/`. In your assistant, you therefore add **one connector per client**, clearly named. No data flows between instances: a token issued by one client is worthless at another.

On the client side, the admin invites you with a role that fits your engagement — store and API, say, without invoicing — plus the **API & Developers** permission needed to connect. They then see your connection listed per machine (“Claude Code, on Karim’s laptop”) and can revoke it at any time, with immediate effect. Your client stays in control of the access it has given you.

Your own agency can run on Ondes PRO too. If it groups several companies, **workspaces** keep them apart (parent company and subsidiaries): the assistant targets the one you name, and a subsidiary never sees another’s data.

## A day at an agency with a coding assistant

**9am.** Project stand-up. You ask your assistant what is overdue on the Kanban board of each redesign in progress; it answers project by project and suggests meetings to schedule.

**10:30am.** Development. Your developer is wiring payments into a client’s site. Instead of digging through documentation, their assistant queries the client’s MCP server: it finds the right resource, reads its required fields, checks what the API does not do, then runs a trial in test mode.

**3pm.** Acceptance testing. The client wants to see the checkout flow. Test mode’s simulated payment page lets you walk through it end to end, with no real card and no fake order in their figures.

**5pm.** Go-live. The site is linked to the client’s GitHub repository; every `git push` redeploys it on their domain.

## Wiring up a payment without opening the docs

_Example conversation · demo data (Atelier Lumen)_

> **You** : On Galerie Ressac’s site, wire the “Buy” button on the print page: create the order and take a card payment.
>
> 🔧 `ondes_chercher` “order payment” — the `shop/commandes` resource and the guide section on payments.
>
> 🔧 `ondes_ressource` `shop/commandes` sheet: required fields, amount recomputed server-side, test twin available.
>
> 🔧 `ondes_impossible` Confirms no route returns an already-issued secret: the payment `client_secret` is only returned at creation.
>
> 🔧 `ondes_appeler` `POST shop/commandes` — test mode stated; trial order created, with a simulated payment page (`paiement.checkout_url`).
>
> **Assistant** : The trial works in test mode. I added the server-side call, the card form mounted with Stripe.js loaded through a `<script>` tag (no new dependency), and the confirmation page. Before going live, Galerie Ressac will need to connect its Stripe account in its configuration — only their admin can do that, since it decides where the money lands.

## Why developers save time

- **Documentation that is always accurate**: it is generated from the client instance’s real routes on every call, and only covers the modules enabled there.
- **A light footprint**: about 2,700 permanent tokens for the eight tools, versus 44,000 for the old documentation file people copied into every repository — and which went stale the moment it was copied.
- **No invented endpoints**: the `ondes_impossible` tool lists what the API deliberately does not do, and `ondes_exemple` provides recipes verified against the real API.
- **Consequence-free trials**: orders, meetings, email sends and invitations go to test mode by default; `simuler: true` validates a body without writing anything.
- **Readable refusals**: a business refusal comes back as a result the assistant understands and fixes, not as a failure.

## The morning project check, across two instances

_Example conversation · demo data (Atelier Lumen)_

> **You** : What is overdue on the Galerie Ressac redesign? And has their store taken any orders since Monday’s launch?
>
> 🔧 `ondes_appeler` Agency connector — `GET kanban/cartes` on the “Galerie Ressac redesign” board: 2 overdue cards.
>
> 🔧 `ondes_appeler` Galerie Ressac connector — `GET shop/commandes` since Monday: 6 real orders.
>
> **Assistant** : Two cards are overdue: “About page copy” (waiting on the client since Thursday) and “Gallery image optimisation” (assigned to Jules). On the store side, **6 orders since Monday**, none with a payment error. Would you like a video call with the client to unblock the copy?
>
> **You** : Yes, Thursday 10am, 30 minutes.
>
> 🔧 `ondes_appeler` Agency connector — `POST visio/reunions` in test mode, then for real once approved: room created, link ready.

## Connecting a client’s existing website to their store

Many clients already have a website and do not want to rebuild it. The “Connect my website” feature, in the store’s **My website** tab, links that site’s code repository — on GitHub or in Ondes GIT — and hands the integration to an AI agent. It reads the code, asks its questions before writing, proposes changes for review, and commits or pushes nothing without an explicit decision. It never force-pushes: on a conflict, it suggests a new branch.

The walkthrough is in the [connect your website](https://ondes.pro/en/integrations/mcp/guides/connect-your-website) guide. To host a static site from GitHub, redeployed on every `git push`, see the [GitHub](https://ondes.pro/en/integrations/github) page.

## Setting up access to a client’s instance

Four steps, done once per client.

1. **Get invited** — The client’s admin sends you an invitation from **Team**, with a role that opens the modules your engagement needs and the **API & Developers** permission.
2. **Add the connector** — In your assistant, add an MCP server named after the client, using their instance address followed by `/mcp/`.

```
https://your-workspace.ondes.pro/mcp/
```
3. **Authorise the connection** — A window from the instance opens: sign in with the account created by the invitation and approve the consent screen.
4. **Check the scope** — Ask the assistant “what can I do here?”: the `ondes_etat` tool lists the connection’s modules and permissions. If a module is missing, the role needs adjusting on the client side.

## For a production integration: the API key

The MCP server is for designing and testing. A website or service running in production calls the REST API with a **scoped API key**: it only reaches the modules and actions required, never exceeds the permissions of the person who created it, and has an adjustable per-minute quota. Signed outgoing webhooks notify your code of a paid order or an issued invoice. Everything is detailed in the [build an integration](https://ondes.pro/en/integrations/mcp/guides/build-an-integration) guide and on the [REST API](https://ondes.pro/en/integrations/rest-api) page.

## Go further

- [Build an integration](https://ondes.pro/en/integrations/mcp/guides/build-an-integration) — Scoped keys, signed webhooks, idempotency and test mode for a back office that never creates duplicates.
- [Connect your website](https://ondes.pro/en/integrations/mcp/guides/connect-your-website) — Show the catalogue and take Stripe payments from a site that is already live, without rebuilding it.
- [Cursor](https://ondes.pro/en/integrations/mcp/clients/cursor) — One `.cursor/mcp.json` file, one OAuth sign-in: Cursor’s agent codes against your real workspace.
- [MCP vs REST API](https://ondes.pro/en/integrations/mcp/mcp-vs-rest-api) — What really sets them apart, when to pick which, and why at Ondes PRO they work together.

## Frequently asked questions

### Can an agency manage several Ondes PRO clients from the same assistant?

Yes: each client has its own instance and MCP server, and you add one connector per client in your assistant. Instances are isolated, and an access token issued for one is rejected by the others.

### Can the client cut off the agency’s access?

Yes, at any time. In the MCP tab of API & Developers, every connection is listed per machine with its last activity, and revocation is immediate. They can also remove the agency’s role or deactivate its account.

### What is the difference between the MCP server and the REST API for an agency?

The MCP server is built for an AI assistant: it serves documentation on demand and runs calls with the signed-in person’s identity. The REST API is built for your production code, with a narrowly scoped key. Both sit on the same resources. See [MCP vs REST API](https://ondes.pro/en/integrations/mcp/mcp-vs-rest-api).

### Can we test a checkout flow without taking money?

Yes. Store orders have a separate test mode, with a simulated payment page and test webhooks kept apart from production ones. Test orders do not show up in the store’s figures.

### What does MCP access cost the agency or its client?

Nothing extra: the MCP server is included in every Ondes PRO plan. The agency’s account simply takes one user seat in the client’s instance.
