Skip to main content
Glama
zackscriven

ghl-mcp-server-v2

by zackscriven
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

ghl_clientportal_request_mobile_apk_build

Requests a signed Android APK build for a published phone app revision, using an idempotency key so retries return the same build.

Instructions

CLIENT PORTAL AI BUILDER API (/ai-builder-api) — side-effecting: opens/edits sandboxes and starts builds. Edit a sandbox only once sandbox.status is ready; checkpoint after edits and before starting the run that builds them; 409 means a cloud build owns the sandbox or it is not running. Build a signed Android APK of a published phone app revision. Idempotent per Idempotency-Key. For a project whose current revision carries generated screens, the build is instead identified by the revision and the generated sources it carries (sha256(locationId:projectId:revision:sourcesSha)): repeating the request for the same revision and sources returns the same build whatever the key, and a failed one is queued again. Such a build is made from the React Native kernel commit the screens were generated against, and must be requested for the current revision. Generated screens reach members only through a new APK; they are never delivered over the air. At most one build may be active per project; sibling projects in the same location may build in parallel. Deleting a project while its build is still queued or building fails that build. A project compiles one signed APK for now: after a successful build the binary is final. A project without generated screens keeps reaching installed apps by publishing a revision; a project with generated screens cannot build another APK yet. Failed builds do not consume the allowance. Endpoint: POST /ai-builder-api/projects/{projectId}/app-config/apk-builds (Version header: v3; source: v3/clientportal-ai-v3.json) OAuth scopes: clientportal-ai.write

Input Schema

NameRequiredDescriptionDefault
bodyYesRequest body (schema carried verbatim from the official OpenAPI spec).
projectIdYesThe app's id.
Idempotency-KeyYesA key you choose for this build. Retrying with the same key returns the same build.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations it discloses concurrency limits (one active build per project, parallel builds across sibling projects), the derived idempotency key sha256(locationId:projectId:revision:sourcesSha), that deletion of a project fails a queued build, and that the resulting binary is final. It also states generated screens are never delivered over the air. Note: 'idempotent per Idempotency-Key' is a conditional guarantee, not a contradiction of idempotentHint=false.

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?

The core purpose sentence sits after a paragraph of API-wide sandbox/build preamble that is only partly relevant to this endpoint. The remaining content is dense but largely earns its place; front-loading the APK-build statement would improve it considerably.

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?

A mutation tool with no output schema and a nested body, and the description covers preconditions, concurrency, idempotency, and failure semantics well. It stops short of describing what the response contains (build id/status) or pointing at ghl_clientportal_get_mobile_apk_build for polling, which an agent still needs.

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%, so the schema already documents all three parameters (baseline 3). The description adds real meaning, notably that for generated-screen apps the revision must be the current revision and that the build identity is derived from revision plus sources hash rather than solely from the Idempotency-Key.

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: 'Build a signed Android APK of a published phone app revision,' plus the exact endpoint path. It is plainly distinguishable from the sibling polling tool ghl_clientportal_get_mobile_apk_build.

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?

Gives substantial conditional guidance: at most one active build per project, generated screens require a new APK, a project with generated screens cannot build another APK yet, failed builds don't consume allowance, and the 409/checkpoint rules. It never names the sibling to poll build status with, and the opening sandbox-editing paragraph is inherited API preamble rather than guidance for this endpoint.

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