# Nomid MDM > Nomid MDM is a mobile device management platform for corporate Android and VR fleets. It supports device enrollment, policy management, app and content distribution, remote access, fleet visibility, and kiosk workflows. ## Product - [Platform overview](https://www.nomidmdm.com/en/features): Explore Nomid MDM capabilities. - [Android Enterprise enrollment](https://www.nomidmdm.com/en/features/enrollment): Review supported enrollment workflows, including QR code and zero-touch enrollment. - [Policy management](https://www.nomidmdm.com/en/features/policies): Configure device rules and restrictions. - [App and content library](https://www.nomidmdm.com/en/features/library): Distribute managed apps and content. - [Kiosk mode](https://www.nomidmdm.com/en/features/kiosk-mode): Configure dedicated-device experiences. - [Remote access](https://www.nomidmdm.com/en/features/remote-access): Support managed devices remotely. - [Pricing](https://www.nomidmdm.com/en/pricing): Compare plans and included capabilities. ## AI assistants - [Nomid for Claude](https://www.nomidmdm.com/en/claude): Connect Claude to Nomid with Sign in with Nomid to ask about Android and VR devices, policies and enrollment. The assistant is instructed to ask before it sends a command. - [Nomid for ChatGPT](https://www.nomidmdm.com/en/chatgpt): Add Nomid to ChatGPT as a connector and sign in with Nomid. - [Nomid for Codex](https://www.nomidmdm.com/en/codex): Add Nomid to Codex as an MCP server with an API key. - [Nomid for Cursor](https://www.nomidmdm.com/en/cursor): Add Nomid to Cursor as an MCP server with an API key. ## Buyer guides - [Comparisons and buyer's guides](https://www.nomidmdm.com/en/comparisons): Guides for choosing Android and VR device management software. - [Best MDM for MSPs managing Android across client companies](https://www.nomidmdm.com/en/comparisons/best-mdm-for-msps): Compare 7 platforms by client separation, Android Enterprise coverage, pricing and RMM fit. - [Partner program](https://www.nomidmdm.com/en/partners): Reseller and managed service provider partnerships for Android and PICO fleets. ## Use cases - [Education](https://www.nomidmdm.com/en/use-cases/education): Android device management for schools. - [Logistics](https://www.nomidmdm.com/en/use-cases/logistics): Manage field and warehouse devices. - [Retail](https://www.nomidmdm.com/en/use-cases/retail): Manage point-of-sale and kiosk fleets. - [Healthcare](https://www.nomidmdm.com/en/use-cases/healthcare): Manage shared and dedicated healthcare devices. ## Learn and build - [Blog](https://www.nomidmdm.com/en/blog): Android Enterprise, device security, deployment, and fleet-management guides. - [Documentation](https://www.nomidmdm.com/en/docs): Product documentation and setup guidance. - [Developer documentation](https://www.nomidmdm.com/en/developers): REST API documentation and integration guidance. - [MCP server for AI assistants](https://www.nomidmdm.com/en/developers/mcp): Connect claude.ai, ChatGPT or Claude Code with Sign in with Nomid, or any MCP client with an API key, to query devices and policies, set up kiosk mode, send device commands and create provisioning QR codes. - [Install instructions for AI agents](https://www.nomidmdm.com/install.md): Steps an agent follows to connect a person to Nomid MDM in Claude, Claude Code, ChatGPT, Codex, Cursor or another MCP client. - [MCP instructions for AI agents](https://www.nomidmdm.com/agents/nomid-mcp.md): Markdown for agents: how to connect, every tool with the permission it needs, kiosk setup, and the rules for commands and policy changes. - [Agent capability summary](https://www.nomidmdm.com/skill.md): What an AI agent can do with Nomid, the inputs it needs and its constraints. - [Agent skills](https://www.nomidmdm.com/.well-known/agent-skills/index.json): Installable Agent Skills, including nomid-kiosk-setup for setting up kiosk mode on tablets (`npx skills add https://www.nomidmdm.com`). - [Kiosk setup skill](https://www.nomidmdm.com/.well-known/agent-skills/nomid-kiosk-setup/SKILL.md): Step-by-step recipe for kiosk mode through the MCP server. - [Full text for agents](https://www.nomidmdm.com/llms-full.txt): The agent instructions, skills and key kiosk and enrollment facts in one file. - [API authentication](https://www.nomidmdm.com/en/developers/api-reference/authentication): API keys and the permission each endpoint and MCP tool needs. - [Device commands API](https://www.nomidmdm.com/en/developers/api-reference/commands): Send lock, reboot, message, wipe and other commands to one device. - [Policy changes API](https://www.nomidmdm.com/en/developers/api-reference/policy-changes): Read a policy's full configuration, and propose and apply changes to its settings, apps, Wi-Fi and the rest of it, new policies (from scratch or as copies) and rollbacks. - [Provisioning QR codes API](https://www.nomidmdm.com/en/developers/api-reference/provisioning-qr-codes): Create a QR code that enrolls an Android device with a policy. - [Device User sessions API](https://www.nomidmdm.com/en/developers/api-reference/device-user-sessions): Report the logins and logouts of users your own app signs in on a managed device, and read who used which device and when. - [APK publishing API](https://www.nomidmdm.com/en/developers/api-reference/apk-uploads): Publish signed Android app releases from CI with LIBRARY_MANAGE, multipart uploads, track selection and explicit upload resume. - [Android enrollment QR generator](https://www.nomidmdm.com/en/tools/qr-generator): Generate an Android Enterprise enrollment QR code. ## Company and contact - [About Nomid MDM](https://www.nomidmdm.com/en/company): Company information. - [Contact](https://www.nomidmdm.com/en/contact): Contact the Nomid team. - [Schedule a demo](https://www.nomidmdm.com/en/demo): Book a product walkthrough. ## Locales and discovery - Canonical site origin: https://www.nomidmdm.com - Localized site prefixes are /en, /br, /pt, /es, /de, /fr, /el, and /pl. - [XML sitemap](https://www.nomidmdm.com/sitemap.xml): Canonical indexable URLs and available language alternates. --- # https://www.nomidmdm.com/skill.md --- name: nomid-mdm description: Nomid MDM manages company-owned Android and VR devices. Use it to look up devices and policies, change policies (including kiosk mode on tablets), send device commands and create enrollment QR codes through its MCP server. metadata: version: "1.0" homepage: https://www.nomidmdm.com --- # Nomid MDM Nomid MDM is a mobile device management platform for corporate Android and VR fleets: enrollment, policies, app and content distribution, remote access, fleet visibility and kiosk mode. ## What an agent can do Through the MCP server at `https://api.nomid.tech/emm/api/mcp` (Streamable HTTP): - Find and inspect devices, count them by policy, model or status, see installed apps and recent commands. - Read policies and their revisions; propose, show and (after the user approves) apply policy changes: settings, apps, Wi-Fi and the rest of the configuration, new policies, rollbacks. - Set up kiosk mode: lock tablets to one app or a fixed set of apps, with a maintenance password, a dock and kiosk controls. - Send device commands (lock, lost mode, message, reboot, launch app, move to another policy) and, with explicit user consent, destructive ones (wipe, screen lock reset, uninstall apps). - Create an Android enrollment QR code for a policy (valid 24 hours) and diagnose devices that fail to enroll or sync. ## Required inputs - A Nomid account and company, created by a person: https://www.nomidmdm.com/en/signup. Agents cannot create accounts. - A connection: Sign in with Nomid (OAuth 2.1, works in claude.ai, ChatGPT and Claude Code) or an API key from the portal. Scopes and permissions decide which tools work: `mcp:read`, `mcp:devices:command`, `mcp:devices:destructive`, `mcp:provisioning`, `mcp:policies:write`. - From the user, for kiosk setup: the apps (package names or links), single or multi app, a maintenance password of 6 to 64 characters, the policy name and the Wi-Fi details. Never invent these. ## Constraints - Policy changes are proposals: show the change list and get approval before applying. A change rated HIGH (a risky change on a policy with devices, an ordinary change on a policy with 6 or more devices, or almost any change on a policy with 50 or more devices) is refused until a person approves it in the Nomid portal; the agent gets a link for that. - Commands act on real devices at once; destructive commands cannot be undone. Get an explicit yes first. - Enrollment QR codes are live tokens: give them only to the user who asked. - Not available through MCP: remote access sessions, zero-touch and Knox Mobile Enrollment configuration, Nomid's own apps. Link the user to the portal for these. ## Start here - Rules and every tool with its permission: https://www.nomidmdm.com/agents/nomid-mcp.md - Skill for kiosk setup: https://www.nomidmdm.com/.well-known/agent-skills/nomid-kiosk-setup/SKILL.md (install: `npx skills add https://www.nomidmdm.com`) - Skills index: https://www.nomidmdm.com/.well-known/agent-skills/index.json - Human documentation: https://www.nomidmdm.com/en/developers/mcp and https://www.nomidmdm.com/en/docs - Kiosk mode: https://www.nomidmdm.com/en/features/kiosk-mode. Enrollment: https://www.nomidmdm.com/en/features/enrollment - All site text for agents: https://www.nomidmdm.com/llms-full.txt. Site map: https://www.nomidmdm.com/llms.txt --- # https://www.nomidmdm.com/agents/nomid-mcp.md # Nomid MDM MCP server > Instructions for AI agents that manage a company's Android and VR devices through Nomid MDM, including setting up kiosk mode on tablets. Human-readable documentation: https://www.nomidmdm.com/en/developers/mcp ## Connect - Endpoint: `https://api.nomid.tech/emm/api/mcp` (MCP Streamable HTTP, stateless). - A person creates the Nomid account and company (https://www.nomidmdm.com/en/signup). You cannot create accounts. - Sign in with Nomid (OAuth 2.1): add the endpoint as a remote MCP server or connector and sign in. Works with claude.ai, ChatGPT and Claude Code. You act as the signed-in user, within their role, their policy scope and the scopes they granted: `mcp:read`, `mcp:devices:command`, `mcp:devices:destructive`, `mcp:provisioning`, `mcp:policies:write`. Clients that follow the server's sign-in challenge ask for `mcp:read`, `mcp:devices:command` and `mcp:provisioning`; a client that sends no scope gets `mcp:read` only; `mcp:devices:destructive` and `mcp:policies:write` must be requested explicitly. The user can untick scopes on the consent page, and Nomid drops what their role or the company's settings do not allow. Policy changes and provisioning also need the company to allow them for agents. - API key: send `Authorization: Bearer ` or `X-API-Key: `. The key's permissions decide which tools work. Never print a key. - Each tool needs its own permission on the key or connection, and a refusal names it. Tell the user which permission is missing; do not work around it. - Companies: an API key, or a connection made for one company, works only in that company. A connection made with "All companies I manage" reaches every company the user manages. `list_companies` lists what the connection reaches, and every other tool takes an optional `company` argument with a `company` value from that list; without it a tool runs in the connection's own company. Naming a company out of reach is a tool error. - REST equivalents of most tools live under `https://api.nomid.tech/emm/api/v1`: https://www.nomidmdm.com/en/developers/api-reference ## Rules 1. Read before you act. Find devices with `search_devices` (use `query` for a name or serial number) and confirm you have the right one before any command. Answer fleet questions with `count_devices` or `get_fleet_summary`, not by paging devices. 2. Commands act on real, physical devices right away. Say what you will do to which devices, naming how many, and get the user's yes before calling `send_device_command`. For several devices make one call with `assetIds` (up to 50) or `devicesInPolicy`, never one call per device. 3. `send_destructive_command` (wipe, screen lock reset or change, relinquish ownership, uninstall apps, clear app data) cannot be undone and Nomid has no approval step for it: tell the user exactly what happens to which device and get an explicit yes first. Never pick a screen lock password yourself. 4. Policy changes are proposals. Read the policy, propose with `propose_policy_change`, `create_policy` or `rollback_policy`, show the user the change list from the proposal, get their approval, then call `apply_policy_proposal`. The proposal's `impact` decides the rest. `NORMAL`: the apply goes through. Nomid cannot verify that the user approved in the conversation, so never apply without asking: the rating only limits how far a change without a person's click can reach. `HIGH` (`requiresPortalApproval` is true; `requiresConfirmation` is a deprecated alias): do not call the apply, which is refused and changes nothing. Give the user the proposal's `approvalUrl` and ask them to approve it in the Nomid portal, after a sign-in at most 10 minutes old. Then read the outcome with `get_policy_proposal`. `confirmation` is ignored. A policy proposal expires after 24 hours; on `stale_proposal`, read the policy again and propose again. Rating: a policy with no devices is NORMAL, except a rollback that restores sections outside the settings catalogue (networks, certificates, kiosk), which is HIGH. Cosmetic changes (messages, display, sound) are NORMAL up to 49 devices. Ordinary changes (settings not flagged risky, adding an app or changing how it installs, unless that blocks it, a third-party app's managed configuration) are NORMAL up to 5 devices. Risky changes are HIGH from 1 device: unknown sources, Play Protect, factory reset, developer options, USB data, encryption, removing or blocking an app, the home screen, a rollback, any other policy edit, and the configuration of the Nomid Settings agent or a secure web app. With 50 or more devices all of these are HIGH. A policy's description, tags and group do not affect devices, so changing them is always NORMAL. Apply an `apps` proposal before proposing a `homeScreen` change that uses those apps. 5. A command answering `UNCONFIRMED` may still have run. Check `list_device_commands` before resending, and never resend without asking the user. On several devices, only the devices in `retryAssetIds` are safe to send again. 6. On a rate limit, wait before trying again: over REST, a 429 with `Retry-After`; over MCP, a tool error saying "Rate limit exceeded ... Retry after N second(s)". Wait that long, and do not loop. A command to several devices costs one unit of the write limit per started group of 5 devices (a call on 50 costs the whole minute) and is refused whole when it does not fit, so send fewer devices or wait. Destructive commands that need `DEVICES_COMMAND_DESTRUCTIVE` also have a limit of 5 per hour per key or connection. 7. When something does not work, call `diagnose` before guessing a cause. Give the user the `portalUrl` of devices and policies you mention, or a link from `get_portal_link`. 8. Create a provisioning QR code only when the user asks for one. Each call creates a live enrollment token valid for 24 hours, and the image can carry the Wi-Fi password: give it only to the user who asked, never repeat the token or password in text, and do not create extra codes "just in case". 9. Never invent secrets or identifiers: a kiosk maintenance password, a Wi-Fi password, a screen lock password, or a package name. Ask the user. 10. A result with `resultTrimmed` lists only the first items: say so and narrow the call. 11. Prices from `search_nomid_site` are public list prices. For the company's own plan use `get_company_plan`; for invoices point the user to Billing in the portal. ## Tools The server offers one tool per kind of action. Device commands, policy changes and diagnosis are chosen by an argument of a shared tool (`command`, a policy part, `area`). ### Read - `search_devices` (`DEVICES_READ`): Page through devices, filtered by status, policy, `lastSyncBefore` (the portal's Last sync: use it for devices not seen or offline since a date), `lastSeenBefore` or `missing` (no IMEI or serial number). To find a device the user names, pass only `query` (name, serial number, IMEI, model or tag). `fields: "names"` returns a compact table. - `count_devices` (`DEVICES_READ`): Count devices with the same filters as search_devices; `groupBy` (`policy`, `model`, `status`) gives an exact breakdown. - `get_device` (`DEVICES_READ`): Full detail of one device by its assetId: status, policy, battery, hardware, location, non-compliance reasons. - `get_fleet_summary` (`DEVICES_READ`): Total devices, a status breakdown and the security posture. Never a device list. - `list_device_commands` (`DEVICES_READ`): The latest commands sent to a device, their outcome and who sent them. Check it before resending a command whose outcome was unknown. - `list_device_apps` (`DEVICES_READ`): The apps a device last reported: package name, name, version, state and who installed them. `query` matches package and name. - `list_device_user_logins` (`DEVICES_READ`): Who logged in on which device, newest first: the device user (`PIN`, `SSO`, or `EXTERNAL` for a user the customer's own system signs in), the asset, `loginAt`/`logoutAt`/`expiresAt`, `open`, and who reported the login and the logout (`DEVICE`, `API`, `EXPIRY`). Filter by `assetId` or `serialNumber`, `deviceUserId` or `externalUserId`, `open`, and `from`/`to`; `limit` defaults to 50, at most 200. Use it for "who is using this device". - `list_companies` (`DEVICES_READ` or `POLICIES_READ`): The companies this connection can work in, with device counts. Needed only when it reaches more than one; every other tool then takes an optional `company` argument (a value from this list). - `list_policies` (`POLICIES_READ`): Every policy with its device count; `query` keeps policies whose name or path name contains it. - `get_policy_settings` (`POLICIES_READ`): The editable settings of a policy with current and allowed values, its apps (package name, name, source, install type, and `managedByNomid` for apps you cannot change) and its current `homeScreen` mode. Read it before proposing a change. - `get_policy_document` (`POLICIES_READ`): A policy's full configuration as JSON, or the part at `path`, a JSON Pointer (an app by package name: `/apps/com.example.app`; kiosk controls: `/kioskCustomization`). Secrets, and every value of an app's managed configuration, read as `{"redacted": true}`. Without a path, apps are summarized. `lockedFields` lists what edits refuse and why; a part over 30,000 characters returns `fieldSizes` instead: read a narrower path. Read it before proposing edits. - `list_policy_revisions` (`POLICIES_READ`): A policy's saved revisions, newest first, for rollback_policy. - `get_policy_proposal` (`POLICIES_READ`): The current state of a policy change proposal you made. - `find_app` (`POLICIES_READ`): Where one app is: in a policy (`policyId`), the company's library, Google Play (by package name only) and a device (`assetId`). `query` is a package name, a Play Store link or part of an app name. The `answer` says whether the app can be added and how. Use it before adding an app to a policy. - `search_library` (`POLICIES_READ`): The company's Nomid library: published private apps (`kind: "apps"`, the default) or the VR library's web links (`kind: "links"`). Not Google Play and not a policy's apps. - `get_company_plan` (`DEVICES_READ`): The company's own plan, billable device count and device limit. No prices or invoices: point the user to Billing in the portal. With Sign in with Nomid, the user's role also needs to see billing. - `diagnose` (`DEVICES_READ` or `POLICIES_READ`): Diagnose one problem in one call. `area: "remote_access"` or `"policy_sync"` with `assetId` explains why a device cannot be reached or is not applying its policy. `area: "enrollment"` with `policyId` and/or `serialNumber` explains why Android devices fail to enroll with a QR code (Wi-Fi first), and lists what only the person holding the device can check. Returns likely causes with evidence and next steps. - `get_portal_link` (`DEVICES_READ` or `POLICIES_READ`): The Nomid portal URL of a device (`kind: "asset"`), policy, library app or portal page (for example `android_enterprise`, `enroll`, `billing`), to give the user a page to open. - `search_nomid_site` (`DEVICES_READ` or `POLICIES_READ`): Public plans and list prices from www.nomidmdm.com. These are list prices, not the company's own contract. - `read_flagged_chats` (`DEVICES_READ`): Nomid staff only (system administrators signed in with Sign in with Nomid). Customers never get it. ### Device commands Also need the company's device commands setting (Sign in with Nomid). - `send_device_command` (`DEVICES_COMMAND` + `DEVICES_READ`): Run a reversible command on a real device now. `command` is one of `lock_device`, `start_lost_mode`, `stop_lost_mode`, `send_device_message`, `request_status_report`, `force_location_update`, `sync_policy`, `reboot_device`, `shutdown_device`, `launch_app`, `change_device_policy`, plus that command's own arguments. Pass exactly one target: `assetId`, `assetIds` (up to 50) or `devicesInPolicy` (at most 50). A device that cannot take the command does not stop the others: the result lists each device's outcome (`SENT`, `NOT_SENT`, `UNCONFIRMED`, `FAILED`), and `retryAssetIds` lists the `NOT_SENT` devices, which are safe to send again. `lock_device` and lost mode need an Android Management device; `sync_policy`, `shutdown_device` and `launch_app` a Nomid agent (AOSP) device. `change_device_policy` also needs POLICIES_READ. ### Destructive device commands Also needs the company's destructive commands setting (`clear_app_data`: with Sign in with Nomid, its device commands setting). - `send_destructive_command` (`DEVICES_COMMAND_DESTRUCTIVE` + `DEVICES_READ`): Run a command that cannot be undone, on one device (`assetId`); these never go to several devices at once. `command` is `wipe_device` (factory reset a company-owned device, or remove the work profile from a personally owned one), `reset_screen_lock`, `change_screen_lock_password` (a password the user gave), `relinquish_ownership`, `uninstall_apps` or `clear_app_data` (up to 20 packages). Nomid has no approval step for these. `uninstall_apps` needs a Nomid agent (AOSP or PICO) device on agent 4.5.20 or later and runs when the device next checks in, even days later: follow it with list_device_commands; an app its policy installs comes back on the next sync. `clear_app_data` and the screen lock commands need an Android Management device. `clear_app_data` needs only DEVICES_COMMAND. ### Policy changes Also need the company's policy changes setting. - `propose_policy_change` (`POLICIES_WRITE` + `POLICIES_READ`): Propose one change to an existing policy: `policyId` plus exactly one part (`settings`, `apps`, `homeScreen`, `details`, `edits`); for several kinds of change, call it once per part. Nothing changes until the proposal is applied. `settings`: the settings get_policy_settings lists. `apps`: up to 20 changes: `ADD` a Google Play or Nomid Store app by `packageName` (a Play Store link works too), `ADD_WEB_APP` a Nomid secure web app for a `url` (optional `title`, at most 50 characters), `REMOVE`, or `SET_INSTALL_TYPE` (`FORCE_INSTALLED`, `AVAILABLE`, `BLOCKED`). Ask the user for a package name rather than guessing. Nomid's own apps cannot be changed here. `homeScreen`: kiosk mode and the home screen (see Kiosk mode below). `details`: description, tags and policy group. `edits`: up to 30 JSON Pointer edits (`{"op": "SET" | "REMOVE", "path", "value"}`) of the get_policy_document document: Wi-Fi networks, password rules, restrictions, system updates, launcher look, fences, kiosk controls at `/kioskCustomization`, an app's managed configuration. To add a Wi-Fi network use the password the user gave you; never invent one. Removing or blocking an app, or most edits and home screen changes on a policy with devices, are HIGH impact. - `create_policy` (`POLICIES_WRITE` + `POLICIES_READ`): Propose a new policy. When the user names no policy to copy, create it from scratch; do not pick one for them. With `fromPolicyId` it copies that policy; without it the policy starts from Nomid defaults (the Nomid Settings agent, device reporting, Play Protect enforced, the standard Android home screen, no other apps). A new policy has no devices, so its changes are not high impact. Add apps and the kiosk home screen with propose_policy_change. - `rollback_policy` (`POLICIES_WRITE` + `POLICIES_READ`): Propose restoring a policy to one of its revisions (from list_policy_revisions). HIGH impact on a policy with devices. - `apply_policy_proposal` (`POLICIES_WRITE` + `POLICIES_READ`): Apply a proposal after the user approved its change list. A `NORMAL` proposal applies once the user approved. A `HIGH` one is refused with an `approvalUrl` for a person to approve in the Nomid portal; read the outcome with `get_policy_proposal`. ### Provisioning With Sign in with Nomid, also needs the company's provisioning setting. - `create_provisioning_qr_code` (`PROVISIONING` + `POLICIES_READ`): A QR code that enrolls a new or factory-reset Android device with a policy (`policyId`; optional `personalUsage`: `ALLOWED` work profile, `DISALLOWED` fully managed, `USERLESS` dedicated device, and Wi-Fi fields `wifiSsid`, `wifiPassword`, `wifiSecurity`, `wifiHidden`). Call it only when the user asks for a code (rule 8). Each call creates an enrollment token valid for 24 hours; the image goes to the user directly. VR-only policies cannot use it. ## Kiosk mode Kiosk setup is supported end to end: https://www.nomidmdm.com/en/features/kiosk-mode. Use the `homeScreen` part of `propose_policy_change` with `policyId` and: - `mode`: `STANDARD`, `NOMID_LAUNCHER`, `KIOSK_MULTI_APP`, `KIOSK_SINGLE_APP`. `STANDARD` is the device's own home screen, `NOMID_LAUNCHER` the Nomid launcher, `KIOSK_MULTI_APP` Nomid Kiosk locked to a launcher of the policy's apps, `KIOSK_SINGLE_APP` locked to one app. - `kioskApp`: the package name, for `KIOSK_SINGLE_APP`. It must already be in the policy (add it first with the `apps` part and apply that). Nomid Settings cannot be the single app. - `maintenancePassword`: required for `KIOSK_SINGLE_APP`, 6 to 64 characters. The user must give it; never invent or repeat it. It is not shown back. - `dock`: up to 6 policy apps pinned to the launcher (launcher and multi-app only). - `addSystemApps` / `removeSystemApps`: `PHONE`, `CONTACTS`, `CAMERA`, `MESSAGES`, `SETTINGS`, `BROWSER`; `NOMID_LAUNCHER` only, not Nomid Kiosk. Switching changes the agent's install type, the home activity and the kiosk keys together, and is always HIGH impact on a policy with devices, so a person approves it in the Nomid portal. On a new policy with no devices it is NORMAL. Once in kiosk, the status bar, navigation buttons, power button and device settings are edited with the `edits` part at `/kioskCustomization`; read it with `get_policy_document` first. `get_policy_settings` and `get_policy_document` report the current mode as `homeScreen`. Recipe: create or pick a policy, add apps (`find_app`, `apps` part, apply), `homeScreen` part (apply), `create_provisioning_qr_code` with `personalUsage: "USERLESS"` for dedicated tablets, then enroll: a new or factory-reset tablet, tap the welcome screen of the setup wizard six times, connect to Wi-Fi if asked, scan the code. Verify with `search_devices`, `get_device` and `diagnose`; undo with `rollback_policy`. The step-by-step version is the `nomid-kiosk-setup` skill: https://www.nomidmdm.com/.well-known/agent-skills/nomid-kiosk-setup/SKILL.md ## Not available Starting remote access sessions, listing or revoking enrollment tokens, creating zero-touch or Knox Mobile Enrollment configurations, and changing Nomid's own apps (the Nomid Settings agent and the inventory, geolocation, store and remote access apps). Fields that `get_policy_document` lists in `lockedFields` (what Nomid sets itself, and VR settings other than the environment id) cannot be edited. Device User logins and logouts are reported by the customer's own system over REST (`POST /device-user-logins`, permission `DEVICES_COMMAND`); no tool reports them. Send the user to the portal for these (`get_portal_link`). ## More - MCP setup and troubleshooting: https://www.nomidmdm.com/en/developers/mcp - Capability summary for agents: https://www.nomidmdm.com/skill.md - Agent skills index: https://www.nomidmdm.com/.well-known/agent-skills/index.json - Whole-site text for agents: https://www.nomidmdm.com/llms-full.txt - Permissions: https://www.nomidmdm.com/en/developers/api-reference/authentication - Device commands: https://www.nomidmdm.com/en/developers/api-reference/commands - Policy changes: https://www.nomidmdm.com/en/developers/api-reference/policy-changes - Provisioning QR codes: https://www.nomidmdm.com/en/developers/api-reference/provisioning-qr-codes - Android enrollment: https://www.nomidmdm.com/en/features/enrollment - Device User sessions: https://www.nomidmdm.com/en/developers/api-reference/device-user-sessions --- # Key facts: kiosk mode and enrollment - Kiosk mode turns a company-owned Android device into a dedicated endpoint for one app, an approved set of apps, a website or a branded launcher. Product page: https://www.nomidmdm.com/en/features/kiosk-mode - Policies carry the configuration. Devices enrolled under a policy apply it; a change reaches them on their next sync. - An Android enrollment QR code is created for a policy and stops working 24 hours after it is created. To use it, a new or factory-reset device shows the welcome screen of the setup wizard: tap it six times, connect to Wi-Fi if asked, and scan the code. VR-only policies are provisioned with Nomid Ops over USB instead. Guide: https://www.nomidmdm.com/en/developers/api-reference/provisioning-qr-codes - Other enrollment methods, including zero-touch and Knox Mobile Enrollment, are described at https://www.nomidmdm.com/en/features/enrollment - The company must have finished its Android Enterprise enrollment before devices can be enrolled. - Product documentation: https://www.nomidmdm.com/en/docs. Developer documentation: https://www.nomidmdm.com/en/developers --- # https://www.nomidmdm.com/.well-known/agent-skills/nomid-kiosk-setup/SKILL.md --- name: nomid-kiosk-setup description: Sets up kiosk mode on Android tablets with Nomid MDM through its MCP server. Use when the user asks to lock tablets to one app or a fixed set of apps, build a kiosk, signage or point-of-sale device policy, or enroll tablets into a kiosk policy. compatibility: Needs network access and the Nomid MCP server (https://api.nomid.tech/emm/api/mcp) connected with Sign in with Nomid or an API key that has policy changes and provisioning permissions. A person must already have a Nomid account. metadata: author: Nomid version: "1.0" homepage: https://www.nomidmdm.com/en/features/kiosk-mode --- # Set up kiosk mode on tablets with Nomid MDM Follow this recipe when a user wants tablets to run one app or a fixed set of apps. The server rules are in https://www.nomidmdm.com/agents/nomid-mcp.md; read them if you have not. Every policy change is a proposal the user approves. You never apply anything on your own authority. ## 0. Before you start - A human creates the Nomid account and the company: https://www.nomidmdm.com/en/signup. You cannot create accounts. Do not ask for or handle the user's password. - Connect the MCP server at `https://api.nomid.tech/emm/api/mcp`. - Preferred: Sign in with Nomid (OAuth). In Claude Code: `claude mcp add --transport http nomid-mdm https://api.nomid.tech/emm/api/mcp`, then sign in from `/mcp`. The user must grant `mcp:policies:write` and `mcp:provisioning`, and the client has to request `mcp:policies:write` explicitly because the server's sign-in challenge does not ask for it; the company must also allow policy changes and provisioning for agents under AI agent access in the portal. - Alternative: an API key from the portal with `POLICIES_READ`, `POLICIES_WRITE` and `PROVISIONING` (and `DEVICES_READ` for the verification step). Send it as `Authorization: Bearer `. Never print or store the key. - A tool refusal names the missing permission. Tell the user which one and where to grant it (see https://www.nomidmdm.com/en/developers/mcp); do not try to work around it. - If the connection reaches several companies, call `list_companies` and ask which one; then pass `company` on every call. - The company must have finished its Android Enterprise enrollment, otherwise QR codes are refused (409). Send the user to the portal to finish it; use `get_portal_link` with `kind: "page"`, `id: "android_enterprise"`. ## 1. Collect what only the user can decide Ask in one message, with a recommendation: 1. Single app (locked to one app) or multi app (a launcher with the approved apps)? Single is `KIOSK_SINGLE_APP`, multi is `KIOSK_MULTI_APP`. 2. Which apps? Package names or Google Play links, Nomid Store apps, or a web address to open as a secure web app. Ask for a package name rather than guessing one. 3. For a single-app kiosk: the maintenance password, 6 to 64 characters. The user must supply it. Never invent, suggest or repeat it. 4. A name for the policy, and the Wi-Fi network the tablets join during setup. Pass a Wi-Fi password only if the user gave you one. ## 2. Choose or create the policy - `list_policies` (use `query` to find one). To change an existing policy that has devices, say so: a home screen change on a policy with devices is always HIGH impact, so a person must approve it in the Nomid portal and you will get a link for that. - Prefer a new policy for a new kiosk fleet: `create_policy` with `displayName` (and `fromPolicyId` to copy a good baseline). It is a proposal: show it, get approval, then `apply_policy_proposal`. A new policy has no devices, so its changes are NORMAL and apply without a portal step. ## 3. Add the apps - `find_app` with `query` and `policyId` to resolve each app (package name, library, Google Play) and see whether it can be added. - `propose_policy_change` with `policyId` and the `apps` part: a list of changes, up to 20. `ADD` by `packageName`, or `ADD_WEB_APP` with `url` (and optional `title`). Nomid's own apps cannot be added or removed. - Show the change list, get approval, then `apply_policy_proposal`. **Apply this proposal before step 4**: the kiosk app and dock apps must already be in the policy. ## 4. Switch the home screen to kiosk `propose_policy_change` with `policyId` and the `homeScreen` part: - Multi app: `{"mode": "KIOSK_MULTI_APP", "dock": []}` - Single app: `{"mode": "KIOSK_SINGLE_APP", "kioskApp": "", "maintenancePassword": ""}` Notes: `dock` is for the launcher and multi app only. `addSystemApps` and `removeSystemApps` (PHONE, CONTACTS, CAMERA, MESSAGES, SETTINGS, BROWSER) work with `NOMID_LAUNCHER` only, not in Nomid Kiosk. The Nomid Settings app cannot be the single app. A switch that changes nothing is refused. Read the current mode first with `get_policy_document` (it reports `homeScreen`). ## 5. Tune kiosk controls (optional) Status bar, navigation buttons, power button and device settings live at `/kioskCustomization`. Read the current values with `get_policy_document` using `path: "/kioskCustomization"`, then propose `edits` (`{"op": "SET", "path": "/kioskCustomization/", "value": }`). Use only values the document shows; do not guess them. Other useful settings (restrictions, Wi-Fi, password rules) are in `get_policy_settings` and `edits`. For Wi-Fi, never invent a password. ## 6. Review and apply For each proposal: show the change list from the tool result in plain words, then wait for the user's explicit yes. Only then call `apply_policy_proposal`. - If a proposal is HIGH impact (`requiresPortalApproval` is true), do not call `apply_policy_proposal`: it is refused and changes nothing. Give the user the proposal's `approvalUrl` and ask them to approve it in the Nomid portal (sign-in at most 10 minutes old). Then read the outcome with `get_policy_proposal`. Do not pass `confirmation`: it is ignored. - A policy proposal expires after 24 hours. On `stale_proposal`, read the policy again and propose again. - On a rate limit, wait the time the error says; do not loop. ## 7. Enroll the tablets Only when the user asks for a code: - `create_provisioning_qr_code` with `policyId` and `personalUsage: "USERLESS"` (a dedicated device with no user account). Add `wifiSsid`, `wifiSecurity` and `wifiPassword` only with values the user gave you. Each call creates a live enrollment token valid for 24 hours. - Give the QR image only to the user who asked. Never repeat the token or the Wi-Fi password in text, and do not create spare codes "just in case". Create a fresh code instead of reusing an old one. - Tell the user, per tablet: it must be new or factory reset. On the welcome screen of the setup wizard tap six times, connect to Wi-Fi if asked, then scan the code. Details and other enrollment methods (zero-touch, Knox Mobile Enrollment): https://www.nomidmdm.com/en/features/enrollment and https://www.nomidmdm.com/en/developers/api-reference/provisioning-qr-codes. - Do not wipe or factory reset a device yourself. If a tablet needs a reset, tell the user to do it, or follow the destructive-command rules in the nomid-mcp skill with the user's explicit yes. - VR-only policies cannot be provisioned with a QR code. ## 8. Verify - `search_devices` (`query` = name or serial number, or filter by `policy`) and `get_device` to see status, policy and non-compliance reasons. `count_devices` with `groupBy` gives a fleet view. - If a device does not enroll: `diagnose` with `area: "enrollment"` (and `policyId` or `serialNumber`). Wi-Fi is the usual cause; it lists what only the person holding the device can check. If a device is enrolled but does not behave: `diagnose` with `area: "policy_sync"` and `assetId`. - `list_device_apps` shows what the device reports installed. - Give the user the `portalUrl` of the policy and devices. ## 9. Undo `list_policy_revisions`, then `rollback_policy` with `revision` (a proposal; HIGH impact on a policy with devices, so a person approves it in the Nomid portal). Switching `homeScreen` back to `STANDARD` also leaves kiosk. ## Do not - Do not apply without approval, or invent a maintenance password, package name or Wi-Fi password. - Do not send device commands, wipe or lock devices as part of this task. - Do not describe portal click paths from memory. Link the user to https://www.nomidmdm.com/en/features/kiosk-mode, https://www.nomidmdm.com/en/docs and `get_portal_link` URLs instead. --- # https://www.nomidmdm.com/.well-known/agent-skills/nomid-mcp/SKILL.md --- name: nomid-mcp description: Rules and tool map for managing Android and VR device fleets with the Nomid MDM MCP server. Use when connecting to Nomid, looking up devices or policies, sending device commands, changing policies, or creating enrollment QR codes. compatibility: Needs network access and the Nomid MCP server (https://api.nomid.tech/emm/api/mcp), connected with Sign in with Nomid or an API key. metadata: author: Nomid version: "1.0" homepage: https://www.nomidmdm.com/agents/nomid-mcp.md --- # Nomid MDM MCP server Nomid MDM manages a company's Android and VR devices. The full, current instructions for agents are at https://www.nomidmdm.com/agents/nomid-mcp.md: read them before using the tools. Human documentation: https://www.nomidmdm.com/en/developers/mcp. ## Connect - Endpoint: `https://api.nomid.tech/emm/api/mcp` (MCP Streamable HTTP, stateless). - Sign in with Nomid (OAuth 2.1) works in claude.ai, ChatGPT and Claude Code. You act as the signed-in user, within the scopes they grant: `mcp:read`, `mcp:devices:command`, `mcp:devices:destructive`, `mcp:provisioning`, `mcp:policies:write`. The server's sign-in challenge asks for read, device commands and provisioning; a client that sends no scope gets `mcp:read` only, and the destructive and policy-write scopes must be requested explicitly. - API key: `Authorization: Bearer ` or `X-API-Key: `. The key's permissions decide which tools work. Never print a key. - A human creates the account (https://www.nomidmdm.com/en/signup) and the key or connection. A refused tool names the permission it needs. - A connection that reaches several companies lists them with `list_companies`; every other tool then takes an optional `company`. ## Tool map Read: `search_devices`, `count_devices`, `get_device`, `get_fleet_summary`, `list_device_commands`, `list_device_apps`, `list_device_user_logins`, `list_companies`, `list_policies`, `get_policy_settings`, `get_policy_document`, `list_policy_revisions`, `get_policy_proposal`, `find_app`, `search_library`, `get_company_plan`, `diagnose` (areas `remote_access`, `policy_sync`, `enrollment`), `get_portal_link`, `search_nomid_site`. Device commands (one tool each): `send_device_command` (lock, lost mode, message, status report, location, policy sync, reboot, shutdown, launch app, change device policy) and `send_destructive_command` (wipe, screen lock reset or change, relinquish ownership, uninstall apps, clear app data). Policy changes: `propose_policy_change` (`policyId` plus exactly one part: `settings`, `apps`, `homeScreen`, `details`, `edits`), `create_policy`, `rollback_policy`, then `apply_policy_proposal`. Enrollment: `create_provisioning_qr_code`. ## Rules 1. Read before you act. Find a device with `search_devices` (`query` = name, serial number, IMEI or tag), confirm it is the right one, then act. Answer fleet questions with `count_devices` or `get_fleet_summary`, not by paging devices. 2. Commands act on real, physical devices right away. Say what you will do to which device and get the user's yes first. For several devices make one call with `assetIds` (up to 50) or `devicesInPolicy`. 3. Destructive commands cannot be undone and have no approval step in Nomid. Tell the user exactly what happens to which device and get an explicit yes. Never pick a screen lock password yourself. 4. Policy changes are proposals. Show the change list, get the user's approval, then call `apply_policy_proposal`. The proposal's `impact` decides the rest. `NORMAL`: the apply goes through. Nomid cannot verify that the user approved in the conversation, so never apply without asking: the rating only limits how far a change without a person's click can reach. `HIGH` (`requiresPortalApproval` is true; `requiresConfirmation` is a deprecated alias): do not call the apply, which is refused and changes nothing. Give the user the proposal's `approvalUrl` and ask them to approve it in the Nomid portal, after a sign-in at most 10 minutes old. Then read the outcome with `get_policy_proposal`. `confirmation` is ignored. A policy proposal expires after 24 hours; on `stale_proposal`, read the policy again and propose again. Rating: a policy with no devices is NORMAL, except a rollback that restores sections outside the settings catalogue (networks, certificates, kiosk), which is HIGH. Cosmetic changes (messages, display, sound) are NORMAL up to 49 devices. Ordinary changes (settings not flagged risky, adding an app or changing how it installs, unless that blocks it, a third-party app's managed configuration) are NORMAL up to 5 devices. Risky changes are HIGH from 1 device: unknown sources, Play Protect, factory reset, developer options, USB data, encryption, removing or blocking an app, the home screen, a rollback, any other policy edit, and the configuration of the Nomid Settings agent or a secure web app. With 50 or more devices all of these are HIGH. A policy's description, tags and group do not affect devices, so changing them is always NORMAL. 5. A command that answers `UNCONFIRMED` may still have run. Check `list_device_commands` and never resend without asking. 6. On a rate limit, wait the time the error gives. Do not loop. 7. When something does not work, call `diagnose` before guessing a cause. Give the user the `portalUrl` of anything you mention. 8. Create a provisioning QR code only when asked. It is a live 24-hour enrollment token and may carry the Wi-Fi password: give it only to the user who asked. 9. A result marked `resultTrimmed` lists only part of the data: say so and narrow the call. 10. Prices from `search_nomid_site` are list prices, not the company's contract. ## Task skills - Kiosk mode on tablets: the `nomid-kiosk-setup` skill, or https://www.nomidmdm.com/en/features/kiosk-mode for the product page. ## Not available through MCP Starting remote access sessions, listing or revoking enrollment tokens, creating zero-touch or Knox Mobile Enrollment configurations, and changing Nomid's own apps. Link the user to the portal for these (`get_portal_link`).