Connect Claude or any MCP AI agent to your IoT devices

Updated 1 Oct 2026

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.

Once approved, the assistant stays connected without asking again: it holds a credential that lasts an hour and renews it itself for up to 30 days of use. Disconnecting it (see below) ends that immediately; otherwise it will ask for your approval again when the 30 days run out.

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.
Only what you hold is offered. If you're a team member with a limited role, the screen offers only the permissions your role includes; anything else the app asked for goes in the "not granted" list. An app can never get more through you than you have yourself, and if your role is narrowed later, what it holds is trimmed to match.
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, and set alarm limits — set_tag_limits sets the limit, the Watch value and the hysteresis on several tags of a device in one call, and tells the assistant whether the gateway will restart as a result (see Normal, Watch and Alert),
set up uptime monitors — including a heartbeat, where the agent gets the check-in URL and secret it needs to wire your service up,
read devices, gateways, dashboards, rules, and telemetry — a device read includes its current alarm level (Normal, Watch or Alert) and whether its alarms are evaluated on the gateway or in the cloud. Telemetry and latest values (get_telemetry, get_latest_values) come back in the tag's engineering units, the same units as its limits, rules and dashboards; when a tag has a scale factor or offset, the stored raw value is included alongside. History comes back in time buckets — at most 2,000 per answer over at most 400 days; a bucket too fine for the window is widened, and the answer says which one was used,
summarise the whole fleet (get_fleet_summary) — the figures of the Fleet KPI, per tag type: average, minimum and maximum in engineering units, how many stations are in range, on Watch, in Alert, offline or online without a reading in the last hour, plus the stations that need attention — Alert first, then Watch, then offline. It is built from each station's latest reading in the last hour, not from stored history,
read uptime history: availability, coverage and past incidents,
build and edit dashboards — including one with a station variable, by giving a widget "deviceId": "${station}", so a single dashboard serves every station — and duplicate one (clone_dashboard) — the copy keeps pointing at the same devices until the assistant re-points its widgets,
write alert rules — including "tell me when this device goes offline" — and disable them. It can switch a rule on only if that rule does nothing but notify (in-app, email, push); a rule that commands a device, runs a macro, fires a saved action, starts a job, or calls a webhook or MQTT topic is switched on by a person, in the app,
write macros: the step sequences that run on your gateway's own processor. Describe what you want the hardware to do and the assistant can author it, correct it when it doesn't compile, and read it back to you. Writing one moves nothing — see below for what it takes to let an assistant actually run one.

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.

Running a macro: the one thing that touches the real world

Writing a macro moves nothing. Running one does — the gateway drives whatever the sequence says to drive. That is the only way an assistant can affect anything physical, and it takes two separate permissions that you control independently:

The macro:run permission on the connection. Unlike every other permission, it arrives unticked on the approval screen and is skipped by "select all". You tick it deliberately or it is not granted.
The individual macro marked "Let an AI agent run this." A tick box in the macro editor, off by default on every macro you or an assistant creates. An assistant can never set it — not on macros it wrote, not on any other. Any change to the macro's steps clears the tick: the sequence is a new one, and a person with Run macros has to allow it again.

The second one is the real control. A permission decides which software may act; it can't tell you whether a particular sequence is safe to hand over. So Synacl asks you about the sequence, one at a time — and an assistant that is refused is told to ask you to review it, not to look for another way.

Beyond that, a run is deliberately honest about itself:

It refuses an offline gateway. A run is not queued for a gateway that is away, so rather than reporting success into nothing, the assistant is told the run was not sent.
It reports what the gateway said, not what it sent. The assistant waits a few seconds for the gateway to confirm the run started. If it doesn't, the honest answer is unknown — not failed, not done.

An assistant cannot arm a macro to run on its own. Schedules and device-event triggers are set by a person, in the app, whatever permissions the assistant holds — and an assistant cannot change the steps of a macro that already runs on its own, either. A sequence firing at three in the morning with nobody in the building is a decision that stays with you.

None of this is a safety system

The platform bounds what a macro can do — one gateway, one run at a time, aborted by the gateway after ten minutes — but none of that makes a machine safe, and neither does any permission on this page. Abort is a network message and cannot reach a gateway that is offline. Synacl is not safety-rated.

If a machine can injure someone, the protection has to be physical and independent of this platform: a hardwired emergency stop in the power path, interlocks, a safety-rated relay. Grant macro:run for things you would be comfortable letting a colleague start from the next room — and build the installation so that anything worse is physically prevented, not just un-ticked. There is more in Macros.

What it cannot do

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

Delete anything. No devices, gateways, dashboards, rules or macros. An agent can create a duplicate; it cannot remove your data. Deletions stay with a person.
Send raw device commands. No writing a value straight to a relay, valve or actuator. An assistant that moves something does it by running a macro you can read, not by poking a register.
Touch billing. No plan changes, no payment details.
Manage your team. No invites, no role changes, no custom roles.

Four things that look like bugs

Asking the agent to switch something on usually won't work. Direct control is not a permission an agent can hold, so it will tell you it can't. The reason is not only 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, and an assistant reporting "done" the moment it sent one would be reporting the dispatch, not the outcome. The supported route is a macro: a named sequence that reports back when it starts and when it finishes. The assistant can write one for you; running it needs both keys described above.

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.

A monitor that is up but reporting no values. A heartbeat monitor starts with no tags, because only your service knows what it reports. If it pushes a field the monitor has no tag for, the check-in is still accepted — the monitor goes online and silence detection works — but that reading can't be charted or used in a rule until a tag with exactly that field name exists. The agent is told which field names are arriving and can add them for you; so can you, from the banner on the monitor's page. Readings recorded before the tag existed are not lost — they become readable as soon as it does.

Pushing faster than your plan allows. Data sent above your plan's publish rate is dropped rather than queued, and repeated violations suspend the device for a while. The reply to each push says whether it was kept, and how many violations have been counted, so an agent building an integration can see it happening instead of finding out when the data goes missing.

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.

If you manage the team, Team → Agent access lists every app connected by any member of the workspace, and you can disconnect any of them from there. Removing someone from the team disconnects theirs automatically.

See what an agent has done

Each connected app on that screen shows how many calls it made this month and how much data was returned to it, with a View activity link for its recent history.

The activity list covers changes, refusals and errors. Successful reads are counted in the totals but not listed one by one — an assistant answering questions about your fleet can make thousands of read calls a day, and listing them would bury the entries worth seeing. An empty activity list therefore means this agent changed nothing and was never refused, not that it was idle.

Two things are worth looking at:

A refusal means the agent tried something its approved permissions don't cover. If it's work you want it doing, reconnect and approve the scope it names; if it isn't, that is exactly the signal you want.
Data returned is the honest proxy for what an assistant costs you. Everything Synacl sends back lands in the model's context window, which is what your AI provider bills for. Synacl can't see that bill — this figure is the closest thing to it.

If you can Manage members, the totals cover the whole workspace, including apps connected by other members; otherwise they cover your own. The per-app activity list is only that app's.

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.
Check the activity list after a big run. It is the shortest way to see what an agent actually changed, as opposed to what it said it changed.
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, and macro:run only when you want it operating them.
Read a macro before you allow an agent to run it. That is what the per-macro tick box is for. The assistant that wrote it is not the best judge of whether it is right, and its mistakes are plausible-looking rather than obviously broken — the right shape with the wrong pin or the wrong duration.
Be present the first time. Watch the first run of anything an assistant wrote, with your hand near the stop. After that you know what it does.
Disconnect what you aren't using. A connection you've forgotten about is one nobody is reviewing.