> For the complete documentation index, see [llms.txt](https://docs.remote.it/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.remote.it/mcp-server/prompt-library.md). # Prompt Library Forty-plus things to ask your AI assistant once the Remote.It MCP server is connected — fleet triage, diagnostics, access control, commissioning and fleet-wide scripting. Once the [connector is set up](/mcp-server/connect-claude.md), the hardest part is knowing what to ask. This page collects prompts that work, grouped by the job you're trying to get done. You don't need to phrase anything exactly as written. These are starting points — the assistant picks the right [tools](/mcp-server/tools.md) from whatever you actually say. {% hint style="info" %} **Permissions are listed per section.** Each section names the capabilities it needs. If a prompt comes back refused, it is almost always a capability you did not grant when you authorized the connector — re-authorize and approve the ones you need. See [Permissions & Safety](/mcp-server/permissions-and-safety.md). {% endhint %} ## What your assistant can and can't see Worth setting expectations before you start. Remote.It knows about **connectivity and access**: which devices exist, whether they're reachable, what services they expose, who connected to what and for how long. Your assistant can answer all of that directly. Remote.It does **not** store what's happening *inside* your equipment — tank levels, PLC tag values, sensor readings, application metrics. To get at those, the assistant has to reach the device itself, either by opening a connection to a service or by running a script on it. Both are covered below. ## Morning fleet check **Needs:** `device:read` — plus `log:read` for the rows that compare against history The daily triage questions. All read-only — a good place to start if you granted nothing else. | Ask | What the assistant does | | -------------------------------------------------------------------------- | -------------------------------------------------------------- | | "Which of my devices are offline right now?" | `list_devices` filtered by state | | "Anything go offline since yesterday?" | Compares current state against recent session history | | "Show me everything offline for more than 24 hours, worst first" | `list_devices` plus `get_device_sessions` to rank by downtime | | "How many devices do I have, broken down by platform?" | `list_devices`, grouped | | "Which sites have no devices reporting at all?" | `list_devices` for state, then `graphql_query` to group by tag | | "Give me a one-paragraph summary of fleet health I can paste into standup" | Inventory and state, summarized | ## Investigating one device **Needs:** `device:read` — plus `log:read` for connection history When something specific is misbehaving. | Ask | What the assistant does | | ---------------------------------------------------------------------------- | ----------------------------------- | | "Tell me everything about the gateway at the Fremont site" | `get_device` including its services | | "What services does that device expose?" | `get_device` | | "When did it last check in, and how long has it been down?" | `get_device` state and timestamps | | "Has this device been flapping, or is this the first outage?" | `get_device_sessions` over time | | "Who connected to this device in the last month, and for how long?" | `get_device_sessions` | | "Compare this device to the one next to it — what's configured differently?" | `get_device` on both, diffed | ## Connectivity troubleshooting **Needs:** `device:read`, plus `device:connect` to actually open anything (and `log:read` for the last row) | Ask | What the assistant does | | ------------------------------------------------------------------------------------------------ | ------------------------------------------------ | | "Open an SSH connection to the pump controller" | `open_connection`, returns an endpoint | | "Is the HTTP service on that device responding?" | `open_connection` returns a reachable URL to try | | "Open a connection to a device on the same LAN and check whether it can see the one that's down" | `open_connection` to a reachable neighbour | | "Close every connection I've got open" | `close_connection` | | "Which of my devices have an SSH service configured but have never been connected to?" | `list_devices` and `get_device_sessions` | {% hint style="warning" %} `open_connection` returns an endpoint — an address and port. Whether your assistant can then *use* that endpoint depends on the client: an assistant with terminal access (such as Claude Code) can connect to it directly, while a chat-only assistant will hand the endpoint back to you to use yourself. To have the assistant act on the device in any client, use [scripting](#fleet-wide-operations) instead. {% endhint %} ## Bandwidth and usage **Needs:** `log:read` — every prompt here reads session history. `device:read` alone will not answer them | Ask | What the assistant does | | --------------------------------------------------------------- | --------------------------------------------------------------- | | "How much bandwidth did the gateway use this week?" | `get_device_sessions` | | "Which ten devices used the most bandwidth this month?" | `graphql_query` across the account, ranked — see the note below | | "Has bandwidth on the cellular sites gone up since last month?" | Session history compared across periods | | "Which devices had the worst connection latency last week?" | `get_device_sessions` | | "Build me a monthly usage table by site tag" | Sessions grouped by tag | {% hint style="info" %} **Ask for fleet-wide totals in one query.** `get_device_sessions` reads one device at a time, so "rank my whole fleet" answered device-by-device is slow on a large account. Say "use a single GraphQL query for this" and the assistant will pull the whole account's session history in one call instead. {% endhint %} ## Access, sharing and contractors **Needs:** `device:write` Third-party access is where this gets genuinely useful — granting access to a whole site, and auditing who has it, is a sentence each. | Ask | What the assistant does | | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------- | | "Give the new contractor access to the staging devices" | `share_device` | | "Share the Fremont gateway with , and let them run scripts on it" | `share_device` with scripting enabled | | "Give just the SSH service on the Fremont gateway, not the web console" | `share_device` limited to that service | | "The contractor's engagement is over — remove their access to everything I shared" | ⚠ `unshare_device` — confirmation required | | "Who currently has access to this device besides me?" | `graphql_query` — sharing is readable through the API, not through `get_device` | | "Audit it: list every device shared outside my organization" | `graphql_query` across the account | | "Transfer ownership of these devices to the operations account" | ⚠ `transfer_device` — confirmation required | {% hint style="info" %} Ask for the audit before you ask for the change. "Who has access to what?" is a fast question here, and it's the one most teams can't answer quickly by any other means. {% endhint %} {% hint style="warning" %} `share_device` only ever adds access, and `unshare_device` removes a person from the whole device — there is no tool that takes away a single service. To narrow someone's access, unshare and share again naming just the services they should keep. Both tools email the people involved. {% endhint %} ## Tags and networks **Needs:** `device:write` for tags; `network:read` and `network:write` for networks — they are granted separately Tags are what make every other prompt on this page work at fleet scale. Time spent here pays for itself. | Ask | What the assistant does | | ---------------------------------------------------------------------------- | ------------------------------------------------------------ | | "What tags am I using?" | `list_tags` | | "Tag every device at the Fremont site with `site:fremont`" | `add_tags` | | "These devices are all pump controllers — tag them accordingly" | `add_tags` | | "Find devices with no tags at all and suggest tags based on their names" | `graphql_query` for devices with their tags, then `add_tags` | | "Create a network for the water treatment sites and add their HTTP services" | `create_network`, `add_network_connection` | | "What's in the production network?" | `list_networks` | | "Clean up: remove the `temp` tag everywhere it's still set" | `remove_tags` | ## Commissioning a new site **Needs:** `device:write` | Ask | What the assistant does | | --------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | | "Give me the install command for a new Raspberry Pi" | `list_platforms`, then `create_registration_code` — the code's install command registers the device into your account | | "Claim this device — the code is XXXXXXXX" | `claim_device` | | "I don't have a device yet — let me try a connection" | `claim_demo_device` adds Remote.It's hosted demo device to your account | | "Add SSH and HTTP services to the device I just claimed" | `add_service` | | "Set it up like the Fremont gateway — same services, same tags" | `get_device` on the template, then `add_service` and `add_tags` | | "Rename the services so they say what they actually are" | `rename_service` | | "Create a connect link for the HMI so the technician can reach it from a browser" | `set_connect_link` | | "Everything's confirmed working — remove that connect link" | ⚠ `remove_connect_link` | ## Bulk provisioning with products **Needs:** `product:read` and `product:write` — plus manage access on the owning account A product is a reusable device template: a platform, a set of services and a set of tags, which yields one registration command you can run on many devices. If you are commissioning more than a handful of identical devices, define a product once instead of claiming them one at a time. | Ask | What the assistant does | | ----------------------------------------------------------------------- | ---------------------------------------------------------- | | "What device products do I have?" | `list_products`, including each one's registration command | | "Create a product for our Raspberry Pi gateways, tagged `site:fremont`" | `create_product` | | "Add SSH and HTTP service definitions to that product" | `add_product_service` | | "Give me the registration command so I can image fifty of these" | `list_products` | | "Change the tags on the gateway product" | `update_product` | | "Drop the VNC service from the product — we stopped shipping it" | ⚠ `remove_product_service` | | "Retire the old product" | ⚠ `delete_product` | | "Hand the OEM product over to the partner account" | ⚠ `transfer_product` | {% hint style="warning" %} Product edits apply to **future** registrations. Removing a service or deleting a product does not touch devices already registered from it — those keep the services they were built with, but the registration command stops working. Ask the assistant which devices came from a product before you change it. {% endhint %} ## Fleet-wide operations **Needs:** `device:execute`, plus the **Scripting** permission on your account and the target devices This is the highest-impact section and the most gated. Every execution asks you to confirm first. See [Device Scripting](/developer-tools/device-scripting.md). | Ask | What the assistant does | | ----------------------------------------------------------------------- | ----------------------------------------------------------------------- | | "What scripts do I have?" | `list_scripts` | | "Show me what the update script actually does" | `get_script` | | "Run the update script on every device tagged `production`" | ⚠ `run_script` — confirmation required | | "Run the diagnostic script on just the three devices that are flapping" | ⚠ `run_script` on selected devices | | "How's that job going?" | `list_jobs`, `get_job` | | "Which devices failed, and what did they report?" | `get_job_logs` | | "Stop the job — that's not what I wanted" | `cancel_job` | | "Write a script that collects disk usage and upload it" | `create_script` | | "Copy my deploy script into the Field Ops organization" | `get_script` to read it, `create_script` to save it there | | "Delete the old deploy script — we've replaced it" | ⚠ `delete_script` — confirmation required; past jobs keep their history | {% hint style="warning" %} Scripts run real code on real equipment. Read what the assistant proposes before you confirm it, and target a single device before you target a tag. {% endhint %} ## Anything else: the GraphQL escape hatch **Needs:** matches whatever the query reads When no dedicated tool fits, the assistant can query the [GraphQL API](/developer-tools/api.md) directly. It's read-only, so this is the safe place to ask awkward questions. | Ask | What the assistant does | | -------------------------------------------------------------------------------------------------------- | -------------------------- | | "What data can I get about device sessions?" | `search_schema` | | "Pull every device with its owner, tags and last-seen date as a table" | `graphql_query` | | "Export that as CSV" | `graphql_query`, formatted | | "Write me a GraphQL query that finds every device tagged `temporary`, so I can use it in our automation" | Generates a reusable query | | "Which account am I signed in as, and what am I allowed to do?" | `whoami` | ## Getting better answers A few things that consistently help. * **Name things the way you name them.** If your devices are tagged by site, ask by site. The assistant filters on your tags, not on a naming convention it invented. * **Ask for the reasoning on anything destructive.** "Show me which devices that would affect, before you do it" works, and is a good habit. * **Chain the follow-up.** The useful part isn't the first answer, it's "now open a connection to the worst one" — the assistant is still holding the context. * **Ask it to check its own access.** "What can you actually do with the permissions I granted?" saves a round of confusion. ## Next steps * [Tool Reference](/mcp-server/tools.md) — every tool behind these prompts * [Permissions & Safety](/mcp-server/permissions-and-safety.md) — permissions, consent and confirmation gates * [Connect Claude](/mcp-server/connect-claude.md) — set up the connector --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.remote.it/mcp-server/prompt-library.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.