Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@xyte-mcp which devices in the Tel Aviv office went offline this week?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for the Xyte platform API. It gives an AI agent typed, validated access to the public Xyte REST API — endpoint discovery plus a generic call tool — over a local stdio transport.
Reads and writes are both available by default; XYTE_MCP_READ_ONLY=1 makes it a
read-only server.
Xyte is a device management platform: connected device fleets, the spaces they live in, their telemetry and incidents, service tickets, commands, models and warranties. This server puts that API in front of an agent as three tools instead of 77 hand-written ones — it can discover the right endpoint, read its exact contract, and call it with arguments validated against that contract before a request goes out.
Useful for asking an agent to investigate a fleet ("which devices in the Tel Aviv office went offline this week, and what do their open tickets say"), to script routine operations, or to work against the Xyte API without you writing the client.
It runs locally as a subprocess of your MCP host and talks to hub.xyte.io directly — there
is nothing to deploy and no third party in the path.
# In an MCP host, e.g. Claude Code:
claude mcp add xyte -e XYTE_ORG_API_KEY=<your-key> -- npx -y @xyteai/mcpOr configure a host directly:
{
"command": "npx",
"args": ["-y", "@xyteai/mcp"],
"env": { "XYTE_ORG_API_KEY": "<your-key>" }
}Requires Node.js 22 or newer.
MCP servers are loaded when a session starts, so restart your host — or open a new session — after adding it.
Related MCP server: Freshservice MCP Server
Create one in the Xyte portal under Settings → API Keys; see Core API Keys for the walkthrough. An organization key acts as that organization, a partner key as the partner — set whichever scopes you need, or both.
The key is all the tenancy there is: it is bound to its tenant server-side, so there is no tenant or URL to configure.
Platform documentation — concepts, portal guides, how the pieces fit together. | |
The REST API this server wraps: authentication, pagination, every endpoint. | |
The whole documentation set as Markdown, plus the endpoints as OpenAPI — written for agents. Worth pointing your agent at alongside this server. | |
This server's source, issues and releases. |
Everything below is about running the server itself.
Variable | Purpose |
| Organization-scoped API key. |
| Partner-scoped API key. Set either or both. |
| Set to |
| Override the hub base URL. Defaults to |
| Override the entry base URL. |
| Per-request timeout. Defaults to |
The last three are escape hatches for non-production hubs; the defaults are what you want.
XYTE_MCP_ALLOW_WRITES from 0.1.x is still honoured with its original meaning: if it is set
at all, it decides, so a server pinned shut with XYTE_MCP_ALLOW_WRITES=0 stays shut across
the upgrade. Where the two disagree, the restrictive one wins. New configuration should use
XYTE_MCP_READ_ONLY.
Tool | What it does |
| Discover endpoints. Filter by |
| Full contract for one endpoint: path params, query params, body shape, required credential. |
| Invoke an endpoint by key with |
The intended sequence is list → describe → call. Endpoint keys are stable identifiers such
as organization.devices.getDevices; the server rejects unknown keys with suggestions
rather than guessing.
Arguments are validated against the endpoint spec before any request is sent, so a wrong parameter name produces a precise message instead of an opaque HTTP 4xx.
Default: GET/HEAD/POST/PUT/PATCH are all permitted.
DELETE: additionally requires confirm set to the endpoint key verbatim. This holds
even with writes enabled — an irreversible call is the one that cannot be walked back.
XYTE_MCP_READ_ONLY=1: only GET/HEAD can be called. Anything else is refused
before a request is built, and the model is told an operator alone can lift it.
xyte_api_call's MCP annotations (readOnlyHint, destructiveHint) follow the live
configuration, so a host prompts according to what the server can actually do.
Worth knowing before you point it at a live fleet. The caller is a model, and read tools return content a third party can influence — device names, ticket bodies, notes. Nothing stops a model from treating text it just read as an instruction, so the server tells it outright that fleet content is untrusted and that mutating intent must come from you. That is a mitigation, not a guarantee. Prefer read-only when the agent runs unattended, when it is working through content you do not control, or when you simply want to look around:
claude mcp add xyte-ro -e XYTE_ORG_API_KEY=<key> -e XYTE_MCP_READ_ONLY=1 -- npx -y @xyteai/mcpBoth can coexist — register a read-only server for exploration and a writable one for the sessions where you want changes to land.
API keys are never echoed back: output is filtered both by field name (api_key, token,
authorization, …) and by literal secret value.
src/catalog/endpoints.generated.json holds 77 endpoints (63 organization, 14 partner). It
is generated from hub's Bruno collection — hub/docs/api/Xyte Public/ — which is the
upstream source the public API reference is built from, and
committed so this repo has no dependency on a hub checkout at runtime.
Device API endpoints are deliberately excluded: they authenticate as a device with a device access token, not as an operator.
To refresh after an API change:
npm run catalog:generate -- --hub-path ../hub
git diff src/catalog/endpoints.generated.json # review, then commitCI cannot regenerate this (it has no hub checkout), so refreshing it is a maintainer step
in the release checklist. --check verifies a committed file matches a fresh generation:
node scripts/generate-catalog.mjs --hub-path ../hub --checkTo check the server, your credential and production connectivity in one step — independently of any MCP host wiring:
npm run smoke:live -- --key-stdin # paste the key; keeps it out of shell history
# or
XYTE_ORG_API_KEY=<key> npm run smoke:liveIt spawns the built server and drives real MCP requests against the live API. The child is
started with XYTE_MCP_READ_ONLY=1 regardless of your environment, only GET endpoints are
exercised, and the key is never printed — this runs against production, so it cannot mutate
anything. A pass means the whole path works; if this passes but your host still shows
nothing, the problem is the host registration, not the server.
npm install
npm run typecheck
npm test # builds, then runs unit + protocol tests
npm run lint
npm run inspect # build and open the MCP InspectorTwo invariants are enforced by lint rather than convention, because both erode silently:
Nothing but JSON-RPC may reach stdout. On stdio, stdout is the protocol channel; one
stray console.log corrupts the stream and the host disconnects. no-console is an error
in src/; use src/log.ts, which writes to stderr.
Tools take (args, ctx) and nothing else. No environment reads, no transport imports.
Credential resolution and transport wiring live in src/transports/.
That second rule is what keeps the door open for a remote transport (see below).
A release is a pushed semver tag. .github/workflows/publish.yml then packs the tarball,
installs and runs it on Linux, macOS and Windows, re-checks the gates, and publishes to npm
with provenance. The npm token lives on the repo's ci GitHub environment, so it is not
reachable from a run on an arbitrary branch.
Checklist, from main with a clean tree:
# 1. Refresh the endpoint catalog. CI cannot do this — it has no hub checkout —
# so a stale catalog is the one release defect nothing else will catch.
npm run catalog:generate -- --hub-path ../hub
git diff src/catalog/endpoints.generated.json # review, commit if changed
# 2. Verify everything the publish job will verify, locally.
npm run typecheck && npm run lint && npm test
npm run smoke:pack-install # packs, installs, runs the binary
# 3. Bump the version and tag it. The publish job refuses to ship a tag that
# disagrees with package.json.
npm version 0.1.0 --no-git-tag-version
git commit -am "Release v0.1.0" && git push origin main
git tag v0.1.0 && git push origin v0.1.0node scripts/generate-catalog.mjs --hub-path ../hub --check exits non-zero when the
committed catalog is stale, if you would rather assert than diff.
Then verify from a machine that has never seen the repo:
npx -y @xyteai/mcp --version
claude mcp add xyte --scope user -e XYTE_ORG_API_KEY=<key> -- npx -y @xyteai/mcp
claude mcp list | grep -i xyte # expect: ✔ ConnectedMCP servers load at session start, so confirm the tools in a new session.
MCP's OAuth 2.1 authorization applies to HTTP transports; for stdio the specification
directs servers to take credentials from the environment, which is what this server does.
Supporting OAuth is therefore not an additive feature — it means running as a remote HTTP
service, which additionally needs an authorization server (Xyte has none today; hub's
oauth2 gem is a client for Zoho/Salesforce/Zoom), a hosted deployment, and a decision
about whether hub accepts OAuth tokens directly or this server holds customer API keys.
That is a separate program, so v1 ships stdio. The tool layer is written to be
transport-agnostic so it can be reused unchanged: adding src/transports/http.ts plus a
resource-server layer would not touch any tool.
Read tools return fleet data (device names, notes, ticket text) that a third party can
influence, and that data enters the model's context. Treat it as untrusted input — see
Write policy for what the server does about it and where XYTE_MCP_READ_ONLY
is the right call.
The API key sets the blast radius, and it is the one control the model cannot talk its way around. Scope it to what the agent needs.
Prefer passing keys through your host's secret handling rather than committing them into a
shared .mcp.json.
Apache-2.0
Invoke a Xyte platform API endpoint by key. Use xyte_endpoint_describe first if you are unsure of the parameters. Mutating endpoints run unless the server was started read-only; DELETE additionally requires confirm.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Endpoint key from xyte_endpoints_list, e.g. "organization.devices.getDevices". | |
| body | No | JSON request body. Only for non-GET endpoints. | |
| path | No | Path parameter values, e.g. { "device_id": "abc" }. All are required. | |
| query | No | Query parameters. Only names listed by xyte_endpoint_describe are accepted. | |
| confirm | No | Required for DELETE endpoints: pass the endpoint key verbatim to acknowledge. |
| Name | Required | Description |
|---|---|---|
| key | Yes | |
| data | Yes | |
| method | Yes | |
| status | Yes | |
| durationMs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it explains that mutating endpoints run unless the server is read-only, and that DELETE operations require a confirm parameter. This matches the destructiveHint annotation and provides important safety details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste. The most critical information (invocation, prerequisite, mutability, confirm requirement) is front-loaded and clearly conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is concise and appropriately relies on sibling tools for parameter details. With an output schema present, return values don't need elaboration. The description covers the essential behavioral and usage aspects for a generic API caller.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by noting that path parameters are all required and query parameters only accept names listed by xyte_endpoint_describe, which is not evident from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it invokes a Xyte API endpoint by key, which is a specific verb+resource. The sibling tools (xyte_endpoints_list and xyte_endpoint_describe) serve different purposes, so this tool is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to use xyte_endpoint_describe first if unsure of parameters. It also clarifies that mutating endpoints run unless the server is read-only, and DELETE requires a confirm parameter. This provides clear when-to-use and prerequisite guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the full contract for one endpoint: required path parameters, accepted query parameters, body shape and which credential it needs. Call this before xyte_api_call when you are unsure of an endpoint's arguments.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Endpoint key from xyte_endpoints_list, e.g. "organization.devices.getDevices". |
| Name | Required | Description |
|---|---|---|
| key | Yes | |
| url | Yes | |
| title | Yes | |
| method | Yes | |
| bodyType | Yes | |
| mutating | Yes | |
| authScope | Yes | |
| pathParams | Yes | |
| bodyExample | No | |
| description | No | |
| queryParams | Yes | |
| pathTemplate | Yes | |
| requiresConfirm | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds value by specifying the contract contents, including credential needs, beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose, no extraneous information. Every sentence is valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and sibling tools, the description is complete, covering purpose, usage, and parameter semantics without needing to explain return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description enhances understanding by explaining the key parameter originates from xyte_endpoints_list and provides an example format, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it shows the full contract for an endpoint, including path parameters, query parameters, body shape, and credential requirements. It distinguishes itself from siblings by advising to call it before xyte_api_call when unsure of arguments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear directive to use before xyte_api_call when uncertain, providing context for usage. While it doesn't explicitly list when not to use, the guidance is strong and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover Xyte platform API endpoints. Returns compact rows; call xyte_endpoint_describe for a specific endpoint's parameters before calling it. Filter with namespace/group/method/search to keep results small.
| Name | Required | Description | Default |
|---|---|---|---|
| group | No | Restrict to one resource group, e.g. "devices" or "spaces". | |
| method | No | Restrict to one HTTP method. | |
| search | No | Case-insensitive substring match over key, title and path. | |
| readOnly | No | When true, list only non-mutating (GET) endpoints. | |
| namespace | No | Restrict to one credential scope. |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| endpoints | Yes | |
| totalAvailable | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and idempotentHint=true, so the agent knows it's safe. Description adds that returns are 'compact rows,' which is useful but not critical. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. First sentence states primary purpose. Second sentence provides workflow guidance and filtering advice. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description does not need to explain return values. It covers purpose, filtering options, and the workflow to use describe. Complete for this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already explains all 5 parameters. The description briefly mentions filtering with namespace/group/method/search but adds little extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Xyte API endpoints. It distinguishes from siblings by directing to xyte_endpoint_describe for parameter details, and mentions filtering options to narrow results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to call xyte_endpoint_describe for specific endpoint parameters before invoking, and to use filters to keep results small. This guides the agent on proper workflow and when to use filtering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.0xyte_api_callxyte_endpoint_describexyte_endpoints_listEach tool has a distinct role: listing endpoints, describing a specific endpoint, and making an API call. There is no overlap or ambiguity.
All tools start with 'xyte_' and follow a resource_action pattern, but there is a minor inconsistency: 'xyte_endpoints_list' uses plural 'endpoints' while 'xyte_endpoint_describe' uses singular 'endpoint'.
With three tools, the server covers the essential workflow for an API wrapper: discover, describe, and call. It is well-scoped and not excessive or sparse.
The tools provide a complete cycle for interacting with the Xyte API: listing available endpoints, getting detailed parameters for a specific endpoint, and executing the call. No obvious gaps are present.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Give your AI agents the tools to build, manage, and run automation workflows.
Device intelligence for AI agents: Fingerprint events, smart signals, and API key management.
Verified, pay-per-use API tools for AI agents through one authenticated connection.
Connect AI agents to 1000+ apps with managed authentication and tool-calling.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/xyte-io/xyte-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
