Skip to main content
Glama

Phonebox

by dev.phonebox
OverviewDiscussionsAdmin

create phone

create_phone

Create a cloud Android phone and wait until it is ready (usually under two minutes). It costs $0.06 a minute while running. Always park it when you're done. If it is still creating or starting when this returns, call get_phone with its ID and wait "ready" to keep waiting: it only reads, while start_phone would renew the session.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoA name to tell the phone apart, up to 80 characters. The default is its ID.
countryNoWhere the phone appears to be: one of the listed two-letter ISO 3166-1 country codes, such as US or DE. Any other code is refused before a phone is made. Leave it out for any country.
metadataNoUp to 20 string pairs of your own, such as a customer ID. Keys have up to 40 characters and values up to 256.
idle_timeoutNoSeconds after the phone's last activity, its last_active_at, at which it parks itself, from 60 to 3600. Calls move last_active_at at most once every 15 seconds. The default is 300.
max_durationNoThe most seconds this session may run before the phone parks, from 60 to 10800. The default is up to 900, shortened automatically to available credit and the spending limit.
idempotency_keyNoA unique key for this phone. If a call times out, repeat it with the same key and settings to get the same phone instead of a second one. If that phone has failed, create the next one with a new key.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only mark this as a non-read-only, open-world, non-destructive write; the description adds the material behavior an agent cannot infer: provisioning takes under two minutes, it bills $0.06 per minute while running, and it may return before the phone is ready. That cost and timing disclosure is genuinely decision-relevant for a spend-incurring tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four tight sentences, front-loaded with what the tool does and the cost, then the operational rules. The final sentence about get_phone versus start_phone is slightly dense and requires re-reading, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does the necessary work of explaining the return state (may still be creating or starting) and the follow-up call with the returned ID. It stops short of describing the full returned object, but for a 6-param, all-optional tool with full schema coverage this is close to complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so name, country, metadata, idle_timeout, max_duration, and idempotency_key are all already documented in the schema, and the description adds no parameter-level detail beyond the returned ID. Baseline 3 is appropriate when the schema carries the full parameter burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Create a cloud Android phone") plus the completion semantics ("wait until it is ready"), which immediately separates it from siblings like start_phone, park_phone, and get_phone. An agent can identify the operation without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit lifecycle guidance: always park when done, and if the phone is still creating/starting, use get_phone with its ID to keep waiting rather than start_phone, which would renew the session. It names the alternative tool and the condition that selects it, which is exactly the routing an agent needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Phonebox toolsInspect
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources