Xyte MCP Server
Connect your own AI assistant — Claude, Cursor, or any MCP-capable tool — directly to your Xyte fleet.
Overview
The Xyte MCP Server connects the AI assistant you already use — Claude, Cursor, or any similar tool — to your Xyte organization. Once it is set up, you can ask about your fleet in plain language, and your assistant can act on your behalf:
- “Which devices in the Tel Aviv office went offline this week?”
- “Summarize the open incidents on the third floor.”
- “Show me the telemetry history for the projector in Room 4.”
- “Open a ticket for the camera that keeps dropping.”
The server runs on your own computer. Your AI tool starts it in the background, and it talks to Xyte directly — there is nothing to install on a server, and no third party sits between your assistant and your data.
MCP (Model Context Protocol) is simply the standard your AI tool uses to connect to outside systems. You do not need to understand it to follow this page. If your tool has a list of “MCP servers”, “connectors”, or “integrations”, it supports MCP.
MCP Server or AI Teammate?
Both let you ask about your fleet in plain language, and you do not have to choose — many teams use both.
| AI Teammate | MCP Server | |
|---|---|---|
| Where you use it | Built into the Xyte platform — click the AI icon | Inside your own AI tool (Claude, Cursor, and others) |
| Setup | None | A one-time install on your computer |
| Best for | Quick answers while you are already in Xyte | Pulling fleet data into work you are doing elsewhere |
The short version: the AI Teammate brings AI to your fleet, and the MCP Server brings your fleet to your AI.
Requirements
- An AI tool that supports MCP — for example Claude or Cursor.
- Node.js 22 or newer installed on your computer. To check, run
node --versionin a terminal. - An organization API key. See Core API Keys for how to create one in Settings → API Keys.
The key determines what the assistant can see. It is tied to your organization on the Xyte side, so there is no tenant or URL to configure.
How to Install
Claude Code
Run this once in a terminal, replacing <your-api-key> with your organization API key:
claude mcp add xyte --scope user -e XYTE_ORG_API_KEY=<your-api-key> -- npx -y @xyteai/mcpOther AI tools
Tools that take a JSON configuration file expect an entry like this:
{
"mcpServers": {
"xyte": {
"command": "npx",
"args": ["-y", "@xyteai/mcp"],
"env": {
"XYTE_ORG_API_KEY": "<your-api-key>"
}
}
}
}Some tools ask only for the inner xyte object rather than the whole mcpServers wrapper. Check your tool's documentation for where the file lives.
Two things that catch people outInstall it at user scope. The
--scope userflag above makes the server available everywhere. Without it, the server is only visible in the folder you added it from, and it will look like the install silently failed when you work somewhere else.Restart your AI tool. MCP servers are loaded when a session starts, so a session that is already open will not see the new server. Close it and open a new one.
Confirm it is working
claude mcp listThe xyte entry should show ✔ Connected. Then, in a new session, ask your assistant something simple such as “list my Xyte spaces”.
What You Can Ask It
Your assistant has access to 63 read and write operations across your organization — devices, spaces, incidents, tickets, commands, telemetry, users, and more. These are examples rather than a full list.
| Use Case | Sample Prompts |
|---|---|
| Fleet overview | “List all devices in the Amsterdam office” “How many devices do we have per space?” |
| Incident triage | “What incidents are open right now?” “Which incidents have been open more than a day?” |
| Device investigation | “Show me the telemetry history for device X over the past week” “What configuration is device Y running?” |
| Spaces | “Which spaces have no devices in them?” “Move device X to the fourth floor space” |
| Tickets | “Summarize the open tickets for our projectors” “Add a comment to ticket 1234 saying the part has shipped” |
| Commands | “Which commands does device X support?” “Reboot the display in the main lobby” |
| Notes | “What notes are on this device?” “Add a note that this unit is scheduled for replacement” |
| Cross-tool work | “Pull the open incidents from Xyte and draft a status email for the facilities team” “Compare this week's offline devices to last week's” |
The last row is the one that is hard to do any other way — because the assistant is running in your own tool, it can combine Xyte data with everything else you have open.
What It Can Change, and How to Lock It Down
By default, your assistant can both read and act. It can send a command, update a device, or claim a device, using exactly the permissions your API key carries. It cannot do anything you could not do yourself in the portal.
Two safeguards apply:
- Deletions need explicit confirmation. Even with writes available, the assistant has to name the specific operation it intends to run before a delete goes through. It cannot delete something as a side effect of a broader request.
- API keys are never echoed back. The key is filtered out of anything the server returns, so it cannot leak into a conversation transcript.
Running it read-only
Ask yourself where the assistant's information is coming from. It reads your fleet content — device names, notes, ticket text — and some of that is written by people outside your organization. A model reading that text cannot always tell the difference between information and an instruction.
That is not a reason to avoid the server. It is a reason to run it read-only whenever the assistant is working through content you do not control, running unattended, or simply looking around:
claude mcp add xyte-ro --scope user -e XYTE_ORG_API_KEY=<your-api-key> -e XYTE_MCP_READ_ONLY=1 -- npx -y @xyteai/mcpA read-only server refuses anything that would change your fleet, before the request is sent.
You can register both at once — a read-only xyte-ro for exploring, and the standard xyte for sessions where you want changes to land. Ask your assistant to use the read-only one by name when you are just investigating.
Troubleshooting
The server does not appear in my AI tool.
Two likely causes, in order. First, MCP servers load at session start — open a brand new session rather than continuing the one you had open. Second, check you used --scope user; without it the server only exists in the folder you ran the command from.
“No Xyte API key configured. Set XYTE_ORG_API_KEY and/or XYTE_PARTNER_API_KEY.”
The server started but received no key. Re-run the install command with -e XYTE_ORG_API_KEY=<your-api-key>, or check that the env block in your JSON configuration is spelled exactly as shown above.
The assistant says it cannot make a change.
The server is running read-only. Check whether you connected to a server registered with XYTE_MCP_READ_ONLY=1. Only you can lift this, by registering the server again without that setting — the assistant cannot turn it off on request.
A request fails with a permissions error.
The API key carries your organization's permissions. If the key cannot reach a space or device, neither can the assistant. Confirm the key's access in Settings → API Keys.
Nothing works and the errors are unclear.
Run npx -y @xyteai/mcp --version in a terminal. If that fails, the problem is Node.js — confirm node --version reports 22 or newer.
Related
- AI Teammate — the assistant built into the Xyte platform.
- Core API Keys — creating and managing the organization API key this server uses.
Updated about 24 hours ago
