MCP server

What the MCP server does

The Model Context Protocol (MCP) is an open standard that lets AI assistants call tools in other systems. The Nomid MCP server lets an assistant such as Claude Code, Codex or Cursor answer questions about your fleet in plain language, for example how many devices use a policy or which devices have not been seen since a given date, without anyone opening the portal. A key with an extra permission can also lock a device, start or stop lost mode, or send a message to one device.

Endpoint and transport

POST https://api.nomid.tech/emm/api/mcp

The server uses MCP Streamable HTTP in stateless mode. Every JSON-RPC call is an independent HTTPS request, so there is no session to keep alive and no event stream to hold open.

Send your API key as a bearer token or in the X-API-Key header. Most MCP clients only support the bearer form. A missing, invalid or expired key returns 401.

The key fixes the company. No tool accepts a tenant or company argument, and a key can only see its own company's devices and policies.

Create an API key

The MCP server uses the same API keys as the REST API. Create a dedicated key for each assistant so you can revoke it without affecting other integrations.

1. 1

   In the Nomid portal, open Settings and select the API tab.

2. 2

   Click Create API Key and enter a name that identifies the assistant, for example Claude Code read-only.

3. 3

   Choose the permissions described below. If you want the key to stop working on a given date, set an expiration date.

4. 4

   Copy the key when it is shown. It is displayed only once.

Connect your assistant

Store the key in an environment variable named NOMID_API_KEY and never commit it to a repository. The URL in each example is the production endpoint.

claude mcp add --transport http nomid-mdm https://api.nomid.tech/emm/api/mcp \
  --header "Authorization: Bearer ${NOMID_API_KEY}"

[mcp_servers.nomid]
url = "https://api.nomid.tech/emm/api/mcp"
bearer_token_env_var = "NOMID_API_KEY"

{
  "mcpServers": {
    "nomid-mdm": {
      "url": "https://api.nomid.tech/emm/api/mcp",
      "headers": {
        "Authorization": "Bearer ${env:NOMID_API_KEY}"
      }
    }
  }
}

Available tools

Every tool is scoped to the key's company. A device is identified by its assetId, which is the pathName returned by search_devices and get_device. A policy is identified by its policyId, which is the pathName returned by list_policies.

Read tools

Read tools return the same data as the matching REST endpoints and never change anything.

Command tools

Command tools act on exactly one physical device per call. There is no bulk option. Each tool needs DEVICES_COMMAND.

Which devices can receive commands

• Only enrolled devices can receive commands (status ACTIVE, INACTIVE or SYNCHRONIZING). Deleted, reprovisioned and unenrolled assets are rejected.
• Lock and lost mode work only on Android Management (Google-managed) devices. Other device types are rejected.
• A message is a push notification to the Nomid agent on the device, so the device needs a registered push token.
• An asset that belongs to another company behaves exactly like an asset that does not exist.

Not available through MCP or the REST API: reboot, wipe or factory reset, remote access, enrollment tokens, policy changes and resetting the screen lock.

Safety and audit

A command changes something a person is holding. Treat each one as an action that needs a human decision.

• Always confirm with the user before any command. The tool descriptions ask the model to do this, but nothing on the server enforces it. Keep your client's per-tool approval turned on for command tools instead of auto-approving them.
• Never resend a command after an unconfirmed result. If the outcome is unknown, check list_device_commands after the device has had time to respond, and ask the user before sending again. A resend can duplicate a command that was already delivered, and a message shows a second notification.
• A result that says the command was not sent is safe to retry. The command never left Nomid.
• Every command is recorded in the device's command history in the Nomid portal and attributed to the API key that sent it, not to a person. The entry shows api-key, the key id and the key prefix. The history that list_device_commands returns contains only type, status, timestamps and outcome, not who sent the command.
• If a computer or configuration file is compromised, revoke the key from Settings, API. Revoked keys cannot be restored.

Rate limits

Limits are counted per API key in fixed one-minute windows. When you exceed the MCP request limit, the server answers HTTP 429 Too Many Requests with a Retry-After header that gives the seconds until the window resets.

A command tool call counts against both limits. When a command tool call exceeds the command limit, the server returns a tool error instead of an HTTP 429. It is a normal response flagged as an error, and its text says how many seconds to wait. The REST read endpoints do not use the MCP limit.

Troubleshooting

Related documentation

• API key authentication
• Device commands API reference