Privacy notice — smart-me MCP server

Who is responsible

smart-me AG, Riedstrasse 18, CH-6343 Rotkreuz, Switzerland Telephone +41 41 511 09 99, e-mail [email protected]

Swiss Federal Act on Data Protection (FADP) and, where it applies, the EU GDPR — as for every other smart-me service.

What the connector is

A server that lets an AI assistant work with a smart-me account in the customer's name. It holds no account of its own: every request is translated into a call to the smart-me API using the credential the customer's assistant sends along, and the answer goes straight back. It is a translator between the assistant and the API, not a second place where a smart-me account lives.

What happens to credentials

Nothing is stored. A customer signs in to smart-me through the usual smart-me login; the access token that comes out of it is held by the AI assistant, not by this server, and is sent along with each request. The server reads one thing from it — when it expires, so it can ask the assistant for a fresh one instead of failing — and passes it on to the smart-me API untouched. It is never written to a log, a file or a database. The same is true of a smart-me API key, for customers who use one instead.

The server never asks for the customer's own smart-me password, and never sees one — it authenticates with the token or API key above and nothing else.

There is one place where a password does pass through it, and it is not the customer's own: creating a login for a tenant. See the one case where somebody else is contacted below for what happens to it.

What data is read, and where it goes

Whatever a customer asks for. Depending on the request, that can be:

• devices and their measured values, current or historic
• the folder tree of the account
• charging stations, their sessions and their settings
• billing properties (ZEV): units, meter shares, tariffs, invoice positions — and the billing addresses stored with them, which are names, postal addresses and e-mail addresses of tenants
• the account's own e-mail address, to tell one account's saved configurations from another's

The decisive point: the answer to a request goes to the AI assistant the customer connected — Claude, ChatGPT, or another — and therefore to that provider. What the provider then does with it is governed by the agreement the customer has with them, not by this notice or by smart-me. Anyone connecting a smart-me account this way is sending the data they ask about to that provider, and for the billing tools that includes personal data of their tenants. Whoever runs a ZEV should be sure they may do that before they ask.

smart-me neither sees nor controls that leg of the journey. This server transmits nothing to an AI provider on its own initiative: it answers the assistant that asked, and only what was asked for.

The one case where somebody else is contacted

Everything else here answers the customer who asked. The sub-user tools are the exception: creating a login for a tenant, or resending their password link, asks the smart-me cloud to send that tenant an e-mail. The mail comes from smart-me, contains a link for setting a password, and goes to the address the customer gave. Nothing about the conversation is in it.

This only ever happens on an explicit request, the tools say so in their description so that the assistant announces it beforehand, and it can be switched off per call. The tenant's name and e-mail address are written to the customer's own smart-me account, where the customer is the controller — the same as the billing addresses they already store there.

By default no password is disclosed. The account is created with a random value generated on the spot, which is not returned, not logged and not recoverable; the tenant sets their own through the mail.

Two options depart from that, for the case where the addresses belong to the property manager rather than to the tenants and the mail is therefore no use: the customer can have a password generated and returned, or supply one. A password that comes back travels the same way as every other answer — to the AI assistant the customer connected, and therefore to that provider. It is not stored by this server and appears in no log here, but it is in that conversation. The tools say so before they are called and the answer repeats it. Anyone using those options should treat the conversation as holding credentials, and hand them to tenants by a channel the tenant can use.

What is stored

Saved configurations, and only where the feature is switched on. A customer can save the configuration of a billing property under a name, to compare or rebuild it later. What is saved is the configuration: units, meter shares, tariffs, invoice positions, the folder structure, the QR-invoice creditor data and the billing addresses. No measured values — this describes a setup, not a history.

• stored as a JSON file in Azure Blob Storage, in the Azure region West Europe (Netherlands)
• one path per smart-me account, so no account can read or overwrite another's
• readable only by this server, which authenticates with a managed identity — no key exists that could be copied
• saving the same name again replaces what was there
• kept until it is deleted. There is no automatic expiry, and the connector offers no tool that deletes one. A customer who wants a saved configuration removed asks smart-me support, who delete it. [confirm: whether that is the process you want, or whether the connector should get a delete tool — see the note at the end]

Server logs. Ordinary operational logs, kept by Azure App Service for three days. They record which smart-me API endpoint was called and how it answered, and, for logins, the client that connected and the outcome of the token exchange. Deliberately not in them: access tokens, API keys, passwords, and the content of any answer — no meter readings, no addresses, no names.

Nothing else. No conversation, no prompt, no history of what was asked is stored by this server.

Where it runs, and who else is involved

Note that this differs from the main declaration, which says the smart-me servers stand in secure data centres in Switzerland: the MCP server and its storage run in Azure West Europe. The smart-me account itself is unaffected and stays where it was.

No other processor is involved. There is no analytics, no tracking, no cookie: the server has no web interface for a person to visit.

Rights, and how to use them

The rights described in the smart-me data protection declaration apply here as well — information, correction, deletion, restriction, objection, and a complaint to a supervisory authority. The address there is the address for this, too.

Two things are quicker done elsewhere:

• Ending the connection. Disconnecting the connector in Claude, ChatGPT or whichever assistant is used stops all of it at once. The access token can additionally be revoked in the smart-me portal.
• Data in the smart-me account. Deleting a device, a folder or an account is done in the portal or by smart-me support, as it always was — this server only reads and writes what the API allows.

Changes

The current version of this notice is the one published at web.smart-me.com/agb-smart-me-ag, alongside the data protection declaration it belongs to. Material changes are announced there.