Update routing app coverage details, such as upload status and source file checksum, for an existing routing app coverage record in App Store Connect.
Update a routing app coverage. [PATCH /v1/routingAppCoverages/{id}]
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ID from the matching list call. | |
| body | Yes | JSON:API request body (Apple schema: RoutingAppCoverageUpdateRequest). |
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 convey readOnly=false, destructive=false, and idempotent=true. The description adds the HTTP method PATCH and endpoint, which implies partial update semantics, but does not disclose additional behaviors like error conditions, validation, or response format. This is consistent but not rich.
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 extremely concise: a single action phrase plus the endpoint. No wasted words, front-loaded with the action, and easy to scan.
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?
Given the rich schema and annotations, the description is mostly sufficient but omits any mention of return value or update semantics beyond the endpoint. A slightly more detailed statement would make it more complete, but the current level is adequate for an update operation with full schema coverage.
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 clear descriptions for 'id' ('ID from the matching list call') and 'body' ('JSON:API request body'). The description does not add further parameter semantics, so the baseline of 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 clearly states a specific action (Update) on a specific resource (routing app coverage), and the verb 'update' distinguishes it from siblings like create, delete, and get. The inclusion of the HTTP method and path reinforces the intent.
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, such as when to update versus create/delete, or any prerequisites or exclusions. It is silent on usage context, making it minimally useful for choosing between related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.