Skip to main content
Glama

Get an upload link for a cloud iPhone

phone_upload_link

Cloud iPhone: Answers a link for the account's running phone that takes a project folder from this machine (a project without a git link) or a .app built elsewhere, up to 2 GB, and upload_command, which packs the folder it runs in and sends it in one step. Then pass upload to phone_app_run, phone_tests_run or phone_app_control install. size and sha256 together make a link for that one archive instead.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "phone_upload_link"
  }
}

Input Schema

NameRequiredDescriptionDefault
sizeNoWith sha256: the archive's exact size in bytes; the link then takes only that archive
sha256NoWith size: the archive's sha256, which upload is then
session_idNoThe phone; default: the account's running phone

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / sha256 / description
      Previous value: -"The archive's sha256 (shasum -a 256)"New value: +"With size: the archive's sha256, which upload is then"
    • changedInput schema / properties / size / description
      Previous value: -"The archive's exact size in bytes: the link takes only that size"New value: +"With sha256: the archive's exact size in bytes; the link then takes only that archive"
    • removedInput schema / required
      Removed value: -[
      -  "size",
      -  "sha256"
      -]
  2. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations already flag readOnly=false, destructive=false, and openWorld=false, so the description's job is to add behavior, which it does: the 2 GB size cap, that upload_command packs and sends in one step, and that size+sha256 scope the link to a single archive. These are meaningful non-obvious traits beyond the annotations.

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

Conciseness3/5

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

Dense and front-loaded with a 'Cloud iPhone:' prefix, but the two run-on sentences are grammatically tangled ('which upload is then', 'Answers a link'), making them harder to parse than the content warrants. Little is wasted, but clarity suffers.

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

Completeness5/5

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

For a tool whose primary outputs are a link and an upload_command, the description explains what comes back and how to use it, covers the size limit and hash shortcut, and there is no output schema to duplicate. Adequate for correct invocation.

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

Parameters4/5

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

Schema coverage is 100% (baseline 3), but the description still adds the key semantics that size and sha256 must be supplied together to make a single-archive link, and reinforces that session_id defaults to the account's running phone. This clarifies the combinatorial constraint beyond the field-level docs.

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

Purpose4/5

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

States a specific verb+resource: it returns an upload link plus an upload_command for getting a project folder or .app onto a cloud iPhone. The awkward phrasing ('Answers a link') is recoverable from context, and it distinguishes itself from routing siblings by naming phone_app_run/phone_tests_run/phone_app_control.

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

Usage Guidelines4/5

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

Explains the two accepted input forms (a project folder without a git link, or a .app built elsewhere) and the 2 GB bound, then directs the agent where to pass the resulting 'upload' (install tools). It lacks an explicit when-not-to-use, but the alternatives are named.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources