Skip to main content
Glama
Sign In
leeguooooo

iphone-use

by leeguooooo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

phone_flow_publish

Destructive

Publishes a verified iPhone automation flow to the official registry by updating or forking a repo, rebuilding index.json, pushing a branch, and opening a public PR only after user confirmation.

Instructions

Publish a working flow to the official registry through the user's GitHub CLI login: forks if needed, writes the flow and any new app.json, rebuilds index.json, pushes a branch and opens a public pull request. Requires confirm=true only after the user agrees to that publication. First create a draft with phone_flow_draft and prove it with phone_flow_run; use phone_flow_report to report an existing flow problem. Put device/iOS/date in verified_on; unverified flows open a draft PR. source is a local file or installed flow id; aliases are foreground-app labels by language. Returns id, repo, branch, head and pr_url; inspect the URL before retrying a failed publication.

Input Schema

NameRequiredDescriptionDefault
idYesRegistry id to publish as, `<app>/<flow>` lowercase slugs.
noteNoWhat was verified, where, and anything a reviewer should know.
sourceYesFlow file path, or an id installed with `flow add`.
aliasesNoForeground-app labels per language (e.g. ["Health","健康"]).
confirmNoMust be true; set only after the user agreed to open a public PR.
app_nameNoHuman app name, used only when the app is new to the registry.
instanceNoInstalled local instance name, such as i13 or default. Omit to use the configured daemon. No fallback on failure.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.27.3
    • addedInput schema / properties / instance
      Added value: +{
+  "description": "Installed local instance name, such as i13 or default. Omit to use the configured daemon. No fallback on failure.",
+  "type": "string"
+}
  2. First observedv0.21.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true, openWorldHint=true, and non-idempotence, so the safety bar is partly covered. The description adds valuable context beyond that: it forks if needed, writes app.json, rebuilds index.json, pushes a branch, opens a public PR, opens a draft PR for unverified flows, and advises inspecting pr_url before retrying. This is exactly the extra behavioral detail an agent needs.

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?

The description is front-loaded with the core action and packs a lot of useful detail into one paragraph. It is dense but every sentence mostly earns its place; minor deductions for being a single run-on paragraph and for the wasted mention of verified_on.

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?

For a complex, non-idempotent mutation tool with no output schema, the description covers the return fields (id, repo, branch, head, pr_url), the confirmation gate, and retry guidance. It is nearly complete, but the phantom verified_on parameter and thin coverage of instance/app_name/note leave small gaps.

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 the baseline is 3. The description adds a little meaning for source ('local file or installed flow id') and aliases ('foreground-app labels by language'), but it also references a 'verified_on' field that is not present in the schema (which has additionalProperties=false), creating a potential misdirection for the agent.

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 ('Publish a working flow to the official registry') plus the mechanism ('through the user's GitHub CLI login'). It clearly distinguishes itself from sibling tools like phone_flow_draft, phone_flow_run, and phone_flow_report by naming them as prerequisites or alternatives.

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 sequencing: create a draft with phone_flow_draft, prove it with phone_flow_run, and use phone_flow_report for existing problems. It also gives a clear gating condition for confirm=true ('only after the user agrees to that publication'), leaving little ambiguity about when to call it.

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

Deploy Server

Other Tools