Key Takeaways
- list_devices is a conceptual MCP tool name over the same REST account you already use. It is not a second product and not a reason to invent GET /devices in a blog.
- Phase 1 does not require you to ship an MCP server. If you wrap tools, OpenAPI in Developer Center owns paths and fields.
- A device roster is for health and routing (deviceIds on send), not for billing tricks. Plans still meter how many Androids are connected.
- Agents that can list devices can see pairing state. Treat the tool like production API access: scoped keys, audit, no OTP bodies in transcripts.
- You still bring the phones and operator credit. Listing devices does not include airtime.
People search list_devices mcp tool android sms gateway because an agent sidebar offered a “list devices” action and they want to know whether that is a new API. It is not. It is a name for reading the same paired-Android roster the control plane already has. Concepts: what MCP for SMS is. REST vs MCP: MCP server vs REST API. Spec: SMS API documentation.
You need a working Android phone with a SIM and SMS credit from your mobile operator. Operator message costs are yours—we do not sell carrier SMS balance. Service pricing is based on device count and total SMS sent through the gateway. Device and SMS volume pricing.
tool: list_devices
OTP-A · online
BULK-1 · last-seen 4m
SPARE · charging
same REST account
OpenAPI owns the path. This card is a UI over facts you already pay device meters for.
What list_devices is
MCP tools are functions an agent can call with a JSON schema. list_devices should return the paired handsets the account is allowed to see: identifiers you can later pass as deviceIds on send, plus whatever health fields the live spec documents (online/last-seen — confirm names). Model Context Protocol primer: MCP. We do not ship a required MCP server implementation in this phase. If you build one, wrap REST; do not invent a parallel device store.
list_devices is a tool name over the same REST account. It is not a second device API. OpenAPI wins.
Not a second device API
This blog will not paste a GET /devices curl. If that route exists in your current OpenAPI, use it. If the dashboard lists devices through another documented resource, wrap that. Copying a guessed path from an article is how agents 404 in production. Related prompt spoke: list_devices example agent prompt.
Sending remains POST /api/v1/messages with Bearer JSON. Multi-device product: multi-device and dual SIM. Dual SIM is two slots on one phone, not two plan devices and not automatic failover.
What a roster is for
| Agent asks | list_devices should help | Do not invent |
|---|---|---|
| Which phone should take OTP? | Ids + health so you pass deviceIds on send | A “priority=” field the API does not document |
| Is the spare actually online? | Last-seen / online if the spec has them | Battery percent scraped from a screenshot |
| Are we over the plan device cap? | Count of paired devices vs catalog | A tool that “adds a device slot” |
| Did inbound STOP hit this SIM? | Not this tool — inbound is message.received | Parsing SMS bodies inside list_devices |
Setup still happens on glass: device setup. Listing a phone that is not paired does not pair it.
Keys and least privilege
An agent with list_devices can see how many radios you run and which ids are in production. That is reconnaissance. Use a scoped key, log tool calls, and keep the secret out of chat transcripts. Auth walkthrough: MCP auth and API keys. Security: security.
Do not dump OTP message bodies into the agent context because a list call returned a device that recently sent one. Logging guidance: MCP logging and audit.
Ops use, not send
On-call: “which deviceIds are online before I pause bulk.” Finance: “are we at the Business cap of 15.” Support: “is SPARE charging.” Sending OTP remains a separate, confirmed action. Incident posture: Android app outage response.
Free still allows 1 device and 300 SMS lifetime. A list that returns one phone is the plan, not a bug.
Agent checklist
- Tool schema matches live OpenAPI — no guessed paths.
- Read-only key for list; send uses a different confirmation.
- Roster never treated as a billing override.
- No OTP plaintext in tool results or transcripts.
- Human pairs phones in the app; the agent only reads.
Next steps
Confirm the device list in Developer Center, then decide if an MCP wrapper is worth the secret surface. Android app · API guide · Twilio vs Android SMS gateway.
Related product pages
Jump to the live product docs for this topic—not another long-form article.
- SMS API documentationLive endpoint reference
- device and SMS volume pricingPlans and allowances
- Android SMS gateway product guideDefinition, product, and how to buy
- download the Android gateway appGet the APK
