appforshare-mcp

Official

Overview Schema Source Related Servers Discussions Admin

Add an extra share link to a build

add_build_link

Generate an extra install link for one build, each with its own label, optional password, start and stop dates, and install cap, so you can share separate links per client.

Instructions

Make another install link for one build, for example one per client, with its own label, optional password (4 to 128 characters), optional start time and stop date (ISO date times, start before stop) and optional install cap. It opens the same install page with its own count; the build's pause, stop date and cap still apply. Returns the new URL. Ask the person first and pass confirm: true. Pro (3 per build) and Team (20 per build), Developer role.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "build": "<build>",
      "label": "<label>",
      "confirm": "<confirm>"
    },
    "name": "add_build_link"
  }
}

Input Schema

Name	Required	Description
`build`	Yes	Build id or the slug of its install link
`label`	Yes	Name for the owner, for example Client A (testers do not see it)
`confirm`	Yes
`startAt`	No	Opens for installs at this ISO 8601 date time, for example 2026-12-01T09:00:00Z
`password`	No	Password for this link only
`expiresAt`	No	Stop date, ISO 8601 date time, for example 2026-12-31T23:59:59Z
`maxInstalls`	No	Install cap for this link

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.7Nov 13, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare the generic mutate profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the description carries most of the burden and does it well: it discloses inherited constraints (the build's pause, stop date and cap still apply), per-link independent counts, plan quotas (Pro 3, Team 20 per build), the required Developer role, and the return value ('the new URL'). These are non-obvious behaviors an agent could not infer from annotations or schema.

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?

A single dense paragraph that front-loads purpose before constraints and quota/role details. Every clause carries information, though the run-on parenthetical listing of optional fields slightly hurts scannability for an agent parsing constraints.

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?

Covers everything needed to invoke a 7-parameter mutation correctly: required confirmation, permission/role prerequisites, plan quota limits, date ordering, inheritance of build-level controls, and the return value in lieu of an output schema. Nothing material is left ambiguous.

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 86%, so the baseline is 3, but the description adds real meaning beyond the schema: the start-before-stop ordering rule, the password length window framing, and the critical interaction that link-level dates and caps coexist with build-level ones. It does not restate every parameter, which is appropriate given rich schema coverage.

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 ('Make another install link for one build') and immediately scopes it against alternatives by describing the per-client use case. An agent can distinguish this from share_build_with_testers, list_build_links, or set_link_controls without opening any schema.

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 clear context ('one per client') and a strong procedural guardrail: 'Ask the person first and pass confirm: true.' However, it never names an alternative tool (e.g., when to use this versus set_link_controls or list_build_links to inspect existing links), so no explicit when-not guidance is present.

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