Remove builds from a beta tester's assigned list to revoke access. Use this action when a tester should no longer test specific builds.
Unlink builds from a beta tester. [DELETE /v1/betaTesters/{id}/relationships/builds]
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ID from the matching list call. | |
| body | No | JSON:API request body (Apple schema: BetaTesterBuildsLinkagesRequest). |
Changes observed during successful MCP inspections.
v2.0.1Input schema / properties / id / descriptionAdded value: +"ID from the matching list call."v2.0.0Input schema / properties / id / descriptionRemoved value: -"Resource identifier."v1.3.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=true, so the destructive nature is covered. The description adds only the endpoint and repeats 'unlink'; it does not disclose side effects, authorization needs, or the effect on the beta tester's access. No additional behavioral context is provided beyond what annotations and schema already offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence followed by the endpoint. No redundant information, every word earns its place. It is appropriately sized for the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is straightforward, and the schema + annotations cover the mechanics and safety. However, the description does not mention that the body must specify which builds to unlink, nor does it clarify applicability versus sibling remove tools. It is minimally complete but leaves room for ambiguity in complex use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the id parameter described as 'ID from the matching list call' and the body as the JSON:API request body. The tool description adds no extra parameter semantics, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Unlink' with the resource 'builds' and subject 'beta tester', clearly stating the action. It also includes the exact endpoint, which distinguishes it from sibling operations like beta_testers__builds__add or builds__individual_testers__remove.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or related tools such as beta_testers__builds__add or builds__individual_testers__remove. The action is implied but no explicit context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.