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, 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 from whatever you actually say.
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.
"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.
"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)
"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
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 instead.
Bandwidth and usage
Needs: log:read — every prompt here reads session history. device:read alone will not answer them
"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
Access, sharing and contractors
Needs: device:write
Third-party access is where this gets genuinely useful — the access you grant can be scoped and revoked in the same sentence you grant it.
"Give the new contractor access to the staging devices"
share_device
"Share the Fremont gateway with alex@example.com, SSH only"
share_device scoped to one service
"Who currently has access to this device besides me?"
graphql_query — sharing is readable through the API, not through get_device
"Remove the contractor's access to everything"
share_device updated across the fleet
"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
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.
"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"
list_devices, 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
"Claim this device — the code is XXXXXXXX"
claim_device
"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.
"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
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.
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.
"What scripts do I have?"
list_scripts
"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
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.
Anything else: the GraphQL escape hatch
Needs: matches whatever the query reads
When no dedicated tool fits, the assistant can query the GraphQL API directly. It's read-only, so this is the safe place to ask awkward questions.
"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 — every tool behind these prompts
Permissions & Safety — permissions, consent and confirmation gates
Connect Claude — set up the connector
Last updated
Was this helpful?