get_device
Get one device row by uuid, name, OR its PAC PORT — the DIRECT resolver for a KNOWN device: when you already hold a device uuid/name (from traffic rows, audit events, another tool's result) or a per-device PAC/proxy endpoint, call this instead of browsing or paging list_devices. pac_port accepts ...
This record as markdown: /tools/dev-busymate-busymate-devtools/get-device.md
What get_device does on Busymate DevTools
AI agents call get_device to retrieve information from Busymate DevTools without modifying anything. It is typically the context-gathering step in research, monitoring, and reporting workflows, before the agent takes action elsewhere.
| Parameter | Type | Required | Description |
|---|---|---|---|
pac_port | string | number | — | The device's PAC/manual-proxy port, as a number (10807), a PAC hostname (10807.busymate.net), a PAC URL (http://10807.busymate.net/), or host:port. |
deviceName | string | — | Device display name (fallback) |
device_uuid | string | — | Device UUID (preferred) |
Parameters from the server's own tool schema.
Why get_device is rated Low
Even though get_device only reads data, uncontrolled read access leaks sensitive information and racks up API costs: an agent caught in a retry loop can make thousands of calls a minute without anyone noticing.
Risk signalsBulk/mass operation — affects multiple targets
Attacks that exploit this kind of access
The rule that runs get_device safely
PolicyLayer is an MCP gateway: it sits between your AI agents and Busymate DevTools, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For get_device, this is the rule to start with:
get_device is read-only, so it stays allowed. Everything else on the server is denied unless you say otherwise.
The button opens the PolicyLayer dashboard: create your workspace, connect Busymate DevTools, apply this rule, and every get_device call is checked against it from then on.
Questions about get_device
Get one device row by uuid, name, OR its PAC PORT — the DIRECT resolver for a KNOWN device: when you already hold a device uuid/name (from traffic rows, audit events, another tool's result) or a per-device PAC/proxy endpoint, call this instead of browsing or paging list_devices. pac_port accepts EVERY spelling: a bare port (10807), the PAC hostname (10807.busymate.net), a full PAC URL (http://10807.busymate.net/ or https://10807.busymate.net/proxy.pac), or host:port — the leading label of a PAC host IS the device's allocated port. A host with no numeric leading label and no explicit port is REFUSED as ambiguous rather than guessed, and a port owned by NO device returns { ok:true, found:false, note } — a normal complete answer, never an error and never an empty list you could misread as 'unsupported'. Returns the canonical record (uuid, name, model, os_version, setup, last_seen_at) plus found:true and the derived pac_port/pac_url. deviceName matches a device's name EXACTLY — case-insensitively and ignoring surrounding whitespace — OR as an UNAMBIGUOUS LABEL PREFIX: a name that is the whole leading label of exactly one device (ending at a token boundary) resolves DIRECTLY in this one call, so a farm phone named BMDEV0 · 00121132 resolves from just BMDEV0, and BMDEV1 resolves to BMDEV1 · … and NOT BMDEV10 · …. It does NOT match a mid-name word or an extra word (a device TYPE like "iphone", a serial) the name lacks, and a stem that fits more than one device (a bare BMDEV) is NEVER guessed. When a name matches neither exactly nor as a unique prefix you get { ok:true, found:false, query, candidates[] } — the near-miss devices (device_uuid, name, platform, last_seen_at, matched_tokens), ranked by how many of your words their NAME contains: re-issue get_device with the device_uuid of the one you meant. That is the complete answer — do NOT fall back to paging list_devices. Candidates are SUGGESTIONS and are never auto-selected, however few: sibling names like a farm host and the phone under it differ by one token, so picking for you could target the wrong machine. Owner-scoped: without devices:view you may still resolve YOUR OWN device by uuid/name/pac_port (the PAC-port match is pinned to devices you own, so port-guessing can never reach another account). It is categorised as a Read tool in the Busymate DevTools MCP Server, which means it retrieves data without modifying state.
get_device accepts 3 parameters: pac_port, deviceName, device_uuid. The full parameter table on this page comes from the server's own tool schema.
Register the Busymate DevTools MCP server in PolicyLayer and add a rule for get_device: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Busymate DevTools. Nothing to install.
get_device is a Read tool with low risk. Read-only tools are generally safe to allow by default.
Yes. Add a rate_limit block to the get_device rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for get_device. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
get_device is provided by the Busymate DevTools MCP server (https://mcp.busymate.dev). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
More on Busymate DevTools, and thousands of servers like it.
This server
Across the catalogue