Connecting an AI agent (MCP)

What MCP actually is

The Model Context Protocol (MCP) is an open standard for letting an AI assistant call a service's operations directly, rather than guessing about it or asking you to copy things back and forth. Synacl runs an MCP server; an assistant that speaks MCP — Claude, for example — connects to it, you approve what it may do, and from then on it can read and change things in your account through a defined set of operations.

It is worth being plain about what that means. The assistant is an ordinary authorised client, no different in kind from a script you might write. What is different is that the thing deciding which operations to call is a language model, so it can misread your intent, act on a wrong assumption, or do more than you had in mind. That is why the permissions you approve are the real control, not the wording of your request.

Availability. The MCP server is enabled per account. If Settings → API & Agents doesn't offer it, it isn't switched on for you yet.

Connect an assistant

In the assistant, add Synacl as an MCP server using the endpoint https://api.synacl.com/mcp. How you do that depends on the assistant — look for "connectors", "MCP servers", or "integrations" in its settings.
The assistant opens Synacl in your browser. Sign in if you aren't already.
Synacl shows a consent screen describing the app and what it is asking for.
Review it, adjust the permissions, and approve. You are returned to the assistant, connected.

If you decline, nothing is granted and the app is told you refused.

Read the consent screen before you approve

The screen shows:

The app's name, website and logo, and where that identity came from.
The permissions it is asking for, each with a plain-English label — View devices, Create dashboards, and so on.
Anything it asked for that Synacl will not grant, listed separately.
The address it will send you back to when you approve.

Things worth checking:

Did you start this? A consent screen that appears when you weren't connecting anything is a reason to close the tab, not to approve it.
The name and logo are supplied by the app itself. Treat them as a claim about who it is, not proof. If you don't recognise the app or its website, don't approve it.
Untick anything it doesn't need. You can narrow the request — approving fewer permissions than were asked for is always allowed. You cannot widen it, and neither can the app.
A long "not granted" list isn't necessarily alarming. It usually means the app asked for a generic set of permissions and Synacl trimmed it to what agents are allowed to hold. It's still worth a glance, because it tells you what the app expected to be able to do.

What the agent can do

Exactly the permissions you approved, and nothing outside the list that agents are allowed to hold at all. In practice that covers provisioning and reading:

register a gateway and edit its configuration,
add devices, define their tags and parameters, adjust thresholds,
read devices, gateways, dashboards, rules, and telemetry,
build and edit dashboards,
write alert rules and enable or disable them.

It acts inside your workspace, with your account's permissions. If you are a team member with a limited role, the agent is limited the same way — an agent can never do something you couldn't do yourself. That is re-checked on every request, so if your own access is narrowed later, the agent is narrowed at the same moment. Work it creates counts against your plan's limits just like work you do by hand: an agent adding twenty devices uses twenty devices' worth of your allowance.

The full permission list is in Scoped API tokens.

What it cannot do

Deliberately excluded, and not grantable even if you want to:

Delete anything. No devices, gateways, dashboards or rules. An agent can create a duplicate; it cannot remove your data. Deletions stay with a person.
Send device commands. No switching relays, driving valves, or moving actuators.
Touch billing. No plan changes, no payment details.
Manage your team. No invites, no role changes, no custom roles.

Two things that look like bugs

Asking the agent to switch something on won't work. Control is not among the permissions an agent can hold, so it will tell you it can't. There is a second reason beyond caution: a command in Synacl is asynchronous. The platform dispatches it and the device acknowledges separately, some time later — so nothing can confirm inline that the relay actually moved. An assistant reporting "done" the moment it sent a command would be reporting the dispatch, not the outcome, which is exactly the wrong thing to be confident about with physical equipment. Drive actuators from the app, a rule, or a macro.

Asking for historical readings can come back empty. Some plans stream telemetry live but don't store it. On those, live values are available and history is genuinely not there, so the agent gets an empty result — it isn't failing to look. See why isn't my telemetry being stored? and storage and retention.

Disconnect an app

Under Settings → API & Agents, connected apps are listed with when you connected them and when they were last used. Disconnecting one revokes every token it holds at once — it loses access, and getting back in requires a fresh approval from you.

Disconnect when you stop using an assistant, when you approved something you'd rather not have, or whenever you're unsure. Nothing the agent already created is removed by disconnecting; it simply cannot do anything further.

Good practice

Review the work. An agent that provisions a fleet is fast and occasionally wrong. Look at what it created before you rely on it — especially tag names, scale factors, and rule thresholds, where a plausible-looking mistake is easy to miss.
Approve read-only first if you only want the assistant to answer questions about your fleet. Add write permissions when you actually want it building things.
Disconnect what you aren't using. A connection you've forgotten about is one nobody is reviewing.