The Model Context Protocol (MCP) is an open standard for giving an AI assistant a set of well-defined, permission-aware actions against a real system. The Applivery MCP server is Applivery's implementation of it — one endpoint that brings your fleet into Claude, ChatGPT or your own tooling.
Generally Available — and actively evolving. The Applivery MCP server is generally available and supported. It is also an AI-facing product under continuous research and improvement: the tool catalogue, the directory listings and the client integrations change between releases. Assistants can misread results, so review anything consequential before approving it.
How it relates to Applivery Intelligence
| Applivery Intelligence | Applivery MCP | |
|---|---|---|
| What it is | A complete product: chat, dashboards, workflows, proactive monitoring | A connector — one endpoint an assistant talks to |
| Where you use it | Inside the Applivery dashboard | Inside Claude, ChatGPT, or your own tooling |
| Who chooses the model | Applivery | You |
| Licensed by | Seats — see Plans, seats and billing | Your Applivery plan, plus whatever your AI provider charges you |
They are not alternatives so much as two doors onto the same fleet. Applivery Intelligence itself consumes the same MCP catalogue internally — what you get in Claude is the same set of capabilities, driven by a different assistant.
Use Intelligence when you want dashboards, automation and monitoring that keep working when you close the tab. Use MCP when you want your fleet available inside a conversation you are already having, alongside your other tools.
What you can do with it
| Area | Examples |
|---|---|
| Device inventory | Search the fleet, inspect a Device, review installed apps, storage, OS version, encryption state |
| Device actions | Lock, restart, rename, wipe, enable Lost Mode, clear a passcode, disenroll |
| Policies | List and inspect Policies, see what a Device has applied, review sync status, create and update |
| Segments and Audiences | Explore the Segment tree, review membership rules, preview who a change would affect |
| Users and enrollment | Look up people, review Enrollment Templates and tokens |
| App distribution | Review published Apps, builds, stores, and who downloaded what |
| Inventory and assets | Track non-managed assets and link them to enrolled Devices |
| Scripts | Review scripts, their assignments and their execution logs |
| Audit | Query the audit trail — who did what, when, on which entity |
The catalogue currently exposes around 146 individual actions. Which of them your assistant sees depends on your platform mix, your Applivery plan, your permissions, and which of them Applivery publishes on the channel you are using.
Requirements
An Applivery account with access to at least one Workspace. The connector never creates accounts or Workspaces.
Applivery Endpoint Manager (UEM/MDM) or App Distribution, depending on which actions you want. A Workspace with only App Distribution returns no device-management results.
Permissions in Applivery. The connector acts as you.
An AI assistant on a plan that supports connectors. Availability is controlled by Anthropic, OpenAI or your own tooling — not by Applivery.
There is nothing to install, no agent, no network change and no API key to generate. You sign in with your Applivery account through a standard OAuth consent screen.
How it works
You → Claude / ChatGPT → mcp.applivery.ai → api.applivery.io → your Workspace
You ask the assistant something about your fleet.
The assistant picks one of the connector's actions and calls the Applivery MCP server.
The server validates your access token, resolves which Applivery Workspace it belongs to, and calls the Applivery API with your credentials.
The result comes back into the conversation.
Every hop is HTTPS. The assistant never holds a long-lived copy of your Applivery credentials — authorisation is an OAuth session you can revoke at any time.
Connect to Claude
Connector URL: https://mcp.applivery.ai/mcp/anthropic
In Claude, open Settings > Connectors.
Find Applivery and select Connect.
Sign in with your Applivery account in the window that opens.
Review the consent screen — it names the Workspace the connector will act on — and select Authorize.
You are returned to Claude with the connector enabled.
Use this if your organization prefers to add it manually.
Open Settings > Connectors > Add custom connector.
Enter Name
Appliveryand Remote MCP server URLhttps://mcp.applivery.ai/mcp/anthropic.Select Add, then Connect, and complete the Applivery sign-in.
In Team and Enterprise organizations an owner or admin can add the connector once for everybody. Each member still authorises individually and still acts with their own Applivery permissions.
Connect to ChatGPT
Connector URL: https://mcp.applivery.ai/mcp/openai
In ChatGPT, open Settings > Apps & Connectors.
Find Applivery and select Connect.
Sign in with your Applivery account, review the consent screen, and Authorize.
Open Settings > Apps & Connectors > Advanced > Developer mode and enable it. Availability depends on your ChatGPT plan.
Select Create and enter Name
Applivery, MCP server URLhttps://mcp.applivery.ai/mcp/openai, Authentication OAuth.Save, select Connect, and complete the Applivery sign-in.
Depending on the surface you may need to bring the app into the conversation explicitly — type @ and pick Applivery, or name it in the request:
Using Applivery, list the Android Devices that have not checked in for 30 days.
Other MCP clients
Any client that speaks MCP over Streamable HTTP with OAuth 2.1 can connect. Point it at https://mcp.applivery.ai/mcp/anthropic (the Anthropic-shaped catalogue) or ask your Applivery contact which channel suits your client. Authorisation is OAuth 2.1 with PKCE; there is no static API key to paste.
Choosing a Workspace
If your Applivery account reaches more than one Workspace, the connector starts on your default one. To move between them inside a conversation, just ask:
Which Applivery workspaces can I access?
Switch to the Acme Corp workspace.
The switch applies to the rest of that conversation, and does not change your default Workspace in the Applivery dashboard. Data from one Workspace is never mixed into a request against another.
Verifying it works
Ask something read-only first:
How many Devices are enrolled in my Applivery workspace?
The assistant should call the connector and answer with a real count. If it answers from general knowledge, or says it has no access, confirm Applivery shows as connected in the assistant's settings and start a fresh conversation.
Permissions and safety
It acts as you, never above you. Authorisation is your own Applivery account. Your Applivery role is the ceiling — there is no shared service account, no elevated mode, no escalation path.
Every action is purpose-built. There is no generic "call the API" action. Each capability is a separate action with a fixed endpoint, a validated input schema and a documented behaviour. Reads and writes are always separate actions — never one action with a method parameter.
Read and write are labelled for the assistant. Every action publishes machine-readable hints:
| Hint | Meaning | Effect in Claude or ChatGPT |
|---|---|---|
| Read-only | Only reads data | May run without asking each time |
| Destructive | Changes or deletes existing data | Always asks for confirmation |
| Closed-world | Operates only inside your Applivery tenant | Signals a predictable domain |
Applivery deliberately over-labels rather than under-labels: anything that modifies state is marked destructive, including updates, remote Device commands (lock, restart, shutdown, clear passcode, Lost Mode), Segment moves and notifications that reach end users. The only action that reaches outside your tenant is the public app-store search.
Confirmation before anything irreversible. For a destructive action the assistant shows what it is about to do, on which Device, and waits.
For wipe, disenroll and delete: ask for the list first, read it yourself, and only then ask to act on it. Approving a batch you have not read is the one reliable way to get a bad outcome from a good tool.
Rate limiting. Limits apply per client and per authenticated identity, so a runaway loop in an assistant cannot hammer your Workspace. When a limit is hit the assistant receives a clear error and stops rather than retrying blindly.
Transport. HTTPS only, with no plaintext fallback. OAuth 2.1 with PKCE. Tokens issued to the assistant are opaque and short-lived; the upstream Applivery tokens behind them are encrypted at rest.
What Applivery controls
Applivery decides which capabilities are published at all, per channel — Claude, ChatGPT, and direct or internal integrations:
The set of actions available in Claude can differ from the set available in ChatGPT, and both can be narrower than what internal integrations use.
An action published to no channel is served to nobody.
A read-only rollout is a supported configuration: publish only the read actions on the relevant channel and no assistant on it can change anything.
An action that is not published on a channel does not exist for clients on that channel — it is filtered out before the assistant is ever told about it, not merely hidden.
Applivery operates a dedicated console for the connector, covering published tools, rate limits, usage statistics, request logs and per-call traces. It is not a customer-facing surface; if you need a read-only rollout, a narrower catalogue or a usage report, ask your Applivery contact.
Privacy and data handling
What is sent to Applivery: the action to run and its parameters — a Device identifier, a search term, a date range — plus your access token. Applivery does not receive your conversation, your prompt history, your files, or the assistant's memory.
What comes back: the result of that action, trimmed to what the request needs. That result becomes part of the conversation and is then subject to your AI provider's data handling, not Applivery's.
What Applivery records: operational logs for support, debugging, abuse prevention and service quality — which action ran, with which parameters, a summary of the response, whether it failed, how long it took, which Workspace and user it was for, which assistant it came from, and the IP address and user agent.
Action parameters and response summaries can include Device names, user names and email addresses from your fleet, and these are retained in Applivery's operational logs. If your organization has rules about which fleet data may leave your systems, apply them at the point of deciding who you grant the connector to.
See the Applivery privacy policy for the authoritative statement.
Disconnecting
Claude: Settings > Connectors > Applivery > Disconnect.
ChatGPT: Settings > Apps & Connectors > Applivery > Disconnect.
From Applivery: revoke the authorisation in your Applivery account settings.
All three paths invalidate the same OAuth session immediately. Reconnecting requires signing in again.
Troubleshooting
| Symptom | What it means |
|---|---|
| The assistant answers without calling Applivery | The connector is not enabled for that conversation. Confirm it is connected and start a new chat; on ChatGPT, name the app explicitly. |
403 — insufficient permissions |
Your Applivery role does not allow that action. It is not a connector fault. |
| An action you expected is missing | It is not published on that channel. Ask your Applivery contact. |
| Results from the wrong Workspace | Ask the assistant to switch Workspace explicitly. |
| Repeated rate-limit errors | Too many calls in a short window — usually an assistant looping. Start a fresh conversation. |