App Store Connect MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.0.6
Disambiguation4/5
Most tools have clear resource+action names, but a few closely related pairs like create-subscription-availability and create-subscription-price could cause confusion. Overall, an agent can reliably distinguish tools based on their names and descriptions.
Naming Consistency5/5
All tools follow a consistent kebab-case verb_noun pattern (e.g., list-apps, get-build, create-subscription). Verbs like get/list/create/update/remove/add are used predictably.
Tool Count2/5
With 69 tools, the server is heavily over-scoped compared to typical MCP servers, making it difficult for an agent to manage. While the App Store Connect API is large, the tool count exceeds the recommended range and is overwhelming.
Completeness3/5
The tool set covers many core workflows for app versions, TestFlight, subscriptions, and review submissions, but notable gaps exist: no create/delete operations for beta testers, bundle IDs, certificates, or app store version localizations. These gaps may require workarounds but do not entirely block common tasks.
Average 3.9/5 across 69 of 69 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what annotations already declare (readOnlyHint, idempotentHint, destructiveHint). It doesn't mention return structure, pagination, or any edge cases. The phrase 'detailed information' is vague and doesn't disclose what information is included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundancy. It is front-loaded with the action and resource, which is appropriate for this simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with one parameter, the description is adequate but not rich. There is no output schema, and the description doesn't enumerate what 'detailed information' includes, so agents may be uncertain about the return payload. However, the simplicity of the tool reduces the need for extensive documentation.
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%, with a well-described userId parameter. The description doesn't add any additional parameter semantics beyond the schema, so baseline 3 applies. No extra context about the ID format or how to obtain it is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly uses the verb 'Get' with a specific resource ('team member (user)'), distinguishing it from listing tools like list-users. However, it doesn't explicitly differentiate from similar sibling tools like get-actor or get-beta-tester, though the user/team member clarifier provides reasonable specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool vs alternatives. The description simply states what it does, with no mention of prerequisites, contrast with list-users, or situations where another tool might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and idempotent behavior, so the description carries little burden. However, it adds nothing about pagination, filtering, or the 200-app limit, and the phrase 'all apps' is somewhat ambiguous given filter parameters are available.
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 a single, front-loaded sentence with no fluff. It is appropriately sized but largely echoes the title, missing an opportunity to add differentiating value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple list tool with strong annotations and a fully documented schema, so the description is minimally sufficient. However, details like pagination or filter usage are absent from the description, relying entirely on schema and annotations.
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 coverage is 100% with descriptive parameter definitions, so the baseline is 3. The description adds no parameter information but also does not mislead, despite the 'all apps' phrase being compatible with optional filters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of apps via the verb 'Get' and resource 'apps'. It does not explicitly differentiate from sibling list tools, but the resource is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternatives are mentioned. Usage is implied by the tool name and the sibling set (list-apps vs. get-app), but there is no clear contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering the safety profile. The description adds no additional behavioral context such as return format or authentication requirements, but it does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words. It is front-loaded with the verb and resource, making the purpose immediately clear.
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 simple get operation with one parameter and comprehensive annotations, the description is adequate. It clearly states the purpose and implies a detailed response, though it does not enumerate the response fields or error behavior. Given the low complexity, this is sufficient.
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?
The only parameter betaGroupId is fully described in the schema as 'App Store Connect beta group ID', providing complete coverage. The description does not add further semantics, but with 100% schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'beta group', clearly indicating a retrieval operation. The qualifier 'specific' distinguishes it from the sibling tool list-beta-groups, though it does not explicitly mention that distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list-beta-groups. There is no mention of prerequisites, exclusions, or scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the scope that it returns registered devices specifically for development and testing, but does not disclose pagination behavior, default limits, or ordering, which are not covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It states the primary action and resource immediately.
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 straightforward list operation, the combination of schema (with detailed filter/limit descriptions) and annotations (read-only, idempotent) makes the description adequate. However, it does not explain the relationship with get-device or any pagination details, so it is not fully complete.
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?
The input schema has 100% description coverage for all six parameters, including limit and filter fields. The description does not add any additional parameter-level meaning, so it earns the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb phrase 'Get a list' and identifies the resource as 'registered devices for development and testing'. This clearly indicates a list operation, distinguishing it from the singular 'get-device' sibling, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 mentions the context 'for development and testing' but does not say when to prefer this over get-device or other list tools, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, indicating a write operation. The description adds that it can assign a build or set various fields, which gives some context about the update scope. However, it does not disclose side effects, whether the update is partial, or what the response contains. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of about 20 words, front-loaded with the verb 'Update', and every word contributes to understanding the tool's purpose. No redundant or vague phrases.
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?
Given the rich parameter schema and annotations (readOnlyHint, destructiveHint), the description is adequate for an update tool. It covers the essential fields and actions. However, it does not mention the return value or that updates are partial, which would be helpful for a mutation tool with no output schema.
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 coverage is 100%, and the description merely lists parameter names that are already described in the schema (buildId, versionString, copyright, releaseType, downloadable). It adds no extra semantic meaning or relationships between parameters, so it stays at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an App Store version and lists the specific fields that can be modified (build, version string, copyright, release type, downloadable flag). The verb 'update' distinguishes it from create/get, but it does not explicitly differentiate from the sibling tool update-app-store-version-localization, which is a separate resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, prerequisites (e.g., existing appStoreVersionId), or context like 'use this after creating a version' or 'for localizations, use update-app-store-version-localization'. It is purely a statement of functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description merely repeats 'Get' without adding behavioral details such as the structure of the returned information or any side effects, so it adds little beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence without redundant words. It conveys the core purpose directly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple get-by-ID operation with rich annotations, but the description lacks detail about the response format or the meaning of 'detailed information'. It does not mention that the include parameter can fetch related resources, though the schema does. Overall, it is minimally adequate but leaves room for ambiguity about what data is returned.
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?
The input schema provides complete descriptions for both parameters: appId is 'App Store Connect app ID' and include lists valid relationship values with an example. Since schema coverage is 100%, the description does not need to elaborate, but it also adds no additional semantic meaning.
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?
The description uses the specific verb 'Get' with the resource 'app' and explicitly notes 'specific app', distinguishing it from sibling tools like list-apps that retrieve multiple apps. It clearly states the tool returns detailed information about an individual app.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as list-apps or get-app-info. The description does not state prerequisites, exclusions, or when to prefer another tool, leaving the agent without selection context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds no behavioral context beyond these, such as return format, pagination behavior, or data scope. It only restates the tool's purpose, so no additional value over annotations is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that is front-loaded with the key action and resource, and the parenthetical briefly clarifies the domain without redundancy. Every word earns its place, and the description is appropriately sized for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a straightforward list operation with a fully documented schema and rich annotations, but it does not mention return structure or filtering capabilities. Since there is no output schema, a bit more detail about the returned data could improve completeness, though the tool's simplicity makes this only a minor gap.
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?
The input schema has 100% description coverage for all four parameters (limit, filter.app, filter.builds, filter.platform), so the schema fully explains parameter semantics. The tool description adds no parameter explanation, but since the schema is comprehensive, the baseline of 3 is appropriate.
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?
The description clearly states the verb 'List' and the specific resource 'app encryption declarations', with a clarifying parenthetical noting export compliance and encryption usage. This distinguishes it from all sibling list tools (e.g., list-apps, list-builds) that target different resource types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (you use this when you need encryption declarations), but it provides no explicit guidance on when to use it versus alternatives, nor does it mention any exclusions or prerequisites. The tool name and parenthetical give enough context for an agent to infer use, but no direct 'use this when' statement is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds no extra behavioral context such as pagination, response format, or scope limitations beyond what is implied by 'for an app'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters and a minimal description, the text only hints at the version filter, omitting the required app filter and other available filters. While the detailed schema compensates, the description alone is somewhat incomplete and could mislead an agent into thinking version is the only optional filter.
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?
The input schema covers all parameters with 100% coverage, so the description does not need to explain them. It adds one note about 'optionally filter by version' but that is redundant with the schema and does not provide additional meaning for other filters like processingState or preReleaseVersion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'List builds for an app', with a specific verb and resource. It distinguishes from the singular 'get-build' sibling by indicating multiple builds. However, 'for an app' is singular while the filter.app parameter accepts an array, and only the version filter is mentioned, which slightly narrows the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the verb 'List' but no explicit guidance is given about when to use this tool versus alternatives like 'get-build' or 'list-build-beta-details'. No exclusions or preconditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds 'detailed information' but does not specify return shape, 404 behavior, or permissions. It adds minimal behavioral context beyond annotations, but does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It directly and completely states the tool's purpose in minimal space, which is ideal.
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?
This is a simple read-only operation with one parameter and accurate annotations. The description plus schema is sufficient for most invocation scenarios. However, the absence of an output schema means the description could say a bit more about what 'detailed information' includes, but the tool name and domain conventions make it reasonably inferable.
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?
The parameter schema fully describes betaTesterId as 'App Store Connect beta tester ID' (100% coverage). The description adds nothing about parameters, so the schema carries the burden. Baseline 3 is appropriate when schema coverage is high.
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?
The description clearly states the action ('get'), the resource ('beta tester'), and the scope ('specific'), effectively distinguishing it from list tools like 'list-beta-testers' that retrieve multiple testers. The verb and object are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 prerequisites (e.g., needing a betaTesterId) or contrast with list-beta-testers for finding IDs. The usage context is only implied by the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no extra behavioral context (e.g., what fields are returned, auth requirements, or rate limits). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that is front-loaded with the main action and resource. No filler or redundant information.
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?
This is a simple one-parameter lookup tool with rich annotations. The description ('detailed information') implies a comprehensive response, and given the absence of an output schema, it provides adequate context. Could be slightly more explicit about return contents, but not necessary for this simplicity.
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?
The schema provides 100% coverage with a clear description for buildId ('App Store Connect build ID'). The tool description adds no additional parameter information, so the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and resource ('detailed information about a specific build'), which distinguishes it from list operations. However, it does not name sibling alternatives or provide additional differentiation beyond the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is implied: use this tool when you have a specific build ID. But there is no explicit guidance about when to use this versus list-builds or other get tools, nor any exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds minimal behavioral context beyond 'reference for app metadata', not covering details like pagination or return format. The bar is lowered due to annotations, so no contradiction and a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to understanding the tool's purpose.
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?
Given the simple nature of the tool, strong annotations, and fully described schema, the description is adequate. It could mention the default limit or output shape, but these are available via annotations and schema, and no output schema is present. The tool is contextually complete enough for a straightforward list operation.
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%, with each of the three parameters (limit, exists.parent, filter.platforms) already having a clear description. The tool description adds no parameter-specific details, but the schema carries the full burden, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List App Store categories') and the resource, making it easy to understand what the tool does. The parenthetical 'reference for app metadata' adds useful context. While it doesn't explicitly contrast with sibling list tools, the resource is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a reference for app metadata but does not explicitly state when to use it versus other list tools. No exclusions or alternatives are mentioned, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safe read-only nature is fully covered. The description adds only the scoping detail 'registered in your team', which is a minor addition beyond annotations. No extra behavioral traits like pagination or ordering are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the essential action and scope in minimal words.
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?
Given the tool has five filter parameters and no output schema, the description provides a reasonable high-level outcome ('a list of bundle IDs'). Annotations cover the safety profile, and the schema covers parameter details. It lacks explicit return structure but is adequate for a simple read-only list operation.
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 each parameter (limit, filter.id, filter.name, filter.platform, filter.identifier) already has a clear description. The tool description adds no additional semantics beyond the schema, meeting the baseline.
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?
The description clearly states a specific verb ('get a list') and a resource ('bundle IDs registered in your team'). It distinctly separates itself from sibling tools like 'get-bundle-id' (singular) by indicating a plural list operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. While the name suggests a listing operation, there is no explicit mention of when one would choose this over a singular 'get-bundle-id' or other list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering the safety profile. The description adds the clarifying parenthetical 'integrations per app', which is useful context beyond the annotations, but it does not disclose other behavioral aspects like pagination, authentication requirements, or return format. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of ten words, front-loaded with the key action and resource. Every word contributes meaning, with the parenthetical adding useful scope without redundancy.
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?
Given the tool's simplicity (3 optional parameters, no required params, no output schema) and the clear schema descriptions, the short description is adequate. It clarifies what a CI product is ('integrations per app') and the limit/filtering params are self-explanatory. A more complex tool would demand more, but for this listing operation the description is sufficiently complete.
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 all three parameters (limit, filter.app, filter.productType) are fully documented in the schema. The description adds no additional parameter semantics, but the baseline of 3 is appropriate when the schema handles the heavy lifting.
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?
The description 'List Xcode Cloud CI products (integrations per app)' clearly identifies the action (List), the resource (CI products), and adds clarifying scope ('Xcode Cloud', 'integrations per app'). This distinguishes it from sibling list tools like list-builds or list-schemes, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description is purely declarative and does not mention any specific use cases, exclusions, or preferred scenarios. Sibling tools exist for other resources, but the description doesn't help an agent decide when this is the right choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds the context that the list contains 'pending' invitations and is scoped to 'your team', but it does not disclose pagination behavior, response format, or rate limits, so the added value beyond annotations is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that is front-loaded with the core information. There is no filler, repetition, or unnecessary detail.
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 simple list operation with comprehensive schema and annotations, the description is adequately complete. While there is no output schema, the tool's purpose is clear and the schema covers all inputs, so the lack of response details is not a significant gap.
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?
The input schema provides complete descriptions for all four parameters (100% coverage), so the description does not need to elaborate. The description adds no parameter-specific semantic information beyond what the schema already provides, warranting the baseline score.
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?
The description clearly states the tool's action ('Get a list') and resource ('pending user invitations'), and scopes it to 'your team'. This distinguishes it from sibling tools like list-users, which retrieve existing users rather than invitations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 list-users or other invitation-related tools. It implies usage for pending invitations but does not explicitly mention exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and idempotent behavior. The description adds useful context about where actors appear (review submissions and version history), which helps the agent understand the tool's domain. No contradiction with annotations.
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 brief and front-loaded with the primary purpose. The first two sentences are efficient. The final sentence is awkward and introduces confusion, slightly reducing the overall conciseness and structure quality.
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 simple get-by-ID tool, the description covers what an actor is, where IDs come from, and hints at an alternative tool. However, the unclear guidance about list-actors prevents full completeness, and the lack of output schema details is not a major issue given the simplicity.
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?
The input schema has 100% description coverage for the single parameter, already explaining that actorId is an actor ID (user or API key identity) and is often returned in submission/version responses. The tool description adds little beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence clearly states the tool gets an actor (user or API key) by ID, which is a specific verb+resource. It also provides helpful context that actors appear in review submissions and version history. However, the final sentence about using list-actors is confusing and slightly muddles the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description attempts to provide an alternative by mentioning list-actors, but the phrasing 'Use list-actors with known IDs to resolve' is ambiguous. It does not clearly specify when to use get-actor versus list-actors, and the instruction could be misinterpreted as recommending list-actors for known IDs, which seems backwards.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation as read-only, idempotent, and non-destructive. The description adds no extra behavioral context beyond the verb 'Get', which is consistent with annotations. It does not contradict annotations but also provides no additional detail about authentication, rate limits, or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It conveys the essential purpose efficiently and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and good annotations, but with no output schema the description is vague about what 'detailed information' includes. It could clarify the scope of details returned, making the description somewhat incomplete for an agent relying solely on it.
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% for the single parameter 'bundleIdId', which is fully documented as the App Store Connect bundle ID resource ID. The description does not add any further semantic meaning beyond the schema, so the baseline score of 3 is appropriate.
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?
The description clearly states the tool gets detailed information about a specific bundle ID, using a specific verb and resource. It distinguishes itself from the sibling tool 'list-bundle-ids' by emphasizing 'specific' rather than 'list all'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description: you use this tool when you need details for a single bundle ID. However, there is no explicit mention of when not to use it or alternatives like 'list-bundle-ids' for multiple IDs, so guidance remains implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=false and idempotentHint=false, and the description's 'Update' aligns with that. The description adds useful context about the app version scope and ID retrieval, but it doesn't disclose behavioral details like whether unspecified fields remain unchanged or what response to expect, so it's minimal beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence followed by a practical instruction on obtaining the ID. No redundancy or filler; it is immediately useful and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (16 parameters, no output schema), the description is under-specified. It doesn't explain how to set content rating fields, whether updates are partial or full, or what the API returns. The ID source hint is helpful but insufficient for an agent to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 2 of 16 parameters have schema descriptions (13% coverage), and the description compensates only by explaining the source for ageRatingDeclarationId. Other parameters, including the many enum fields (gambling, violenceRealistic, etc.), remain unexplained, so an agent gets little guidance for constructing the request.
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?
The description clearly states the action ('Update'), the resource ('age rating declaration'), and the context ('for an app version (content ratings)'). It differentiates from sibling update tools by targeting a specific object type, and the ID source instruction adds practical scoping.
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?
It gives a clear prerequisite for obtaining the required ID, directing users to get-app-info or get-app-store-version. However, it doesn't explicitly state when not to use this tool or name alternative tools, though the verb and resource are sufficiently unique among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false) and not idempotent or destructive. The description adds that it creates a version and optionally attaches a build, but does not disclose side effects, prerequisites, or response behavior. While it does not contradict annotations, the added behavioral context is minimal beyond the name and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core action and resource, followed by the optional attachment detail. Every phrase adds value; there is no redundancy or filler.
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?
Given the tool's moderate complexity (6 params, 3 required, 2 enums, no output schema) and robust annotations/schema, the description adequately covers the essential purpose and key option. It does not explain return values or prerequisites, but the schema fills parameter details and annotations cover safety. A slightly richer description could have mentioned expected outcomes, but current completeness is strong enough for effective invocation.
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 parameters are already well-documented. The description highlights 'platform + version string' and 'Optionally attach a build', mapping to platform, versionString, and buildId, but adds no new meaning beyond the schema. The baseline of 3 applies due to high 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?
The description clearly states the action: 'Create a new App Store version', specifies the resource ('an app'), and provides key qualifiers ('platform + version string', 'Optionally attach a build'). This distinguishes it from siblings like get/update/list app store versions and other create-* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage—when you need to create a new App Store version—but gives no explicit guidance on when not to use it or alternatives. Sibling tools like update-app-store-version exist, yet the description does not contrast with them. This is an implied usage rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds the gzip compression and decompression behavior, plus the vendor number requirement, giving useful context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short, information-dense sentences with no filler. Each sentence earns its place: the purpose, the prerequisite, and the output format.
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 download tool with no output schema, the description conveys the return format and a required environment variable. It does not discuss error handling or file content structure, but overall it is adequate for the tool's simplicity.
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?
The schema covers all four parameters with descriptions (100% coverage), so the baseline is 3. The description does not add new parameter-level semantics; the mention of APP_STORE_CONNECT_VENDOR_NUMBER simply echoes the vendorNumber parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Download') and the resource ('finance report'), with a format detail (gzip TSV). However, it does not explicitly distinguish from the sibling 'download-sales-report' despite the different report type, so it falls short of a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite ('Requires APP_STORE_CONNECT_VENDOR_NUMBER') and notes the output format, but it does not explicitly say when to use this tool versus alternatives like download-sales-report. Usage context is implied rather than directly specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the operation is known to be safe and side-effect-free. The description adds minimal behavioral context, only noting the returned content is text and that it is app-specific. It doesn't disclose error handling, authorization needs, or pagination, but the annotations cover the key safety traits, so a mid-range score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loading the core purpose in the first sentence and pointing to the update sibling in the second. There is no wasted wording, and it is easily parsed in a quick scan.
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 simple getter operation with rich annotations and a single fully documented parameter, the description is almost complete. It states the return type (text), references the update tool, and the schema fills in the parameter source. The only minor gap is not explicitly mentioning the list alternative within the description itself, but this is covered by the schema and sibling context.
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?
The schema provides 100% coverage with a description for betaLicenseAgreementId, explaining it is the beta license agreement ID from list-beta-license-agreements. The tool description itself doesn't elaborate on the parameter, but the schema does the heavy lifting. With such coverage, the baseline score of 3 is appropriate.
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?
The description clearly states what the tool does: it gets the TestFlight beta license agreement text for an app. It uses a specific verb ('Get') and identifies the resource, and it differentiates from the update sibling by mentioning update-beta-license-agreement. While it doesn't explicitly mention list-beta-license-agreements, the singular 'get' versus 'list' pattern makes the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides only limited guidance on when to use this tool. It points to update-beta-license-agreement for updates, which is an alternative for a different operation, but it doesn't explicitly state when to use this over list-beta-license-agreements or how to obtain the ID. The schema parameter description mentions the ID comes from list-beta-license-agreements, but the description itself does not carry that guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to repeat safety traits. It adds minimal behavioral context beyond scope (specific signing certificate) but does not disclose return format, error behavior, or prerequisites. This is consistent with annotations, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the tool's function without any redundant information. Every word earns its place.
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 simple single-parameter read operation with strong read-only annotations, the description is adequately complete. It clearly identifies the resource and asks for the specific ID. The phrase 'detailed information' could be more specific about return fields, but no output schema exists and the tool's simplicity reduces the need for further elaboration.
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?
The input schema provides 100% coverage for the single parameter certificateId with a clear description ('App Store Connect certificate ID'). The tool description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
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?
The description uses the specific verb 'Get' and the resource 'signing certificate', clearly indicating a read operation for a specific certificate. This distinguishes it from list-certificates and other get-* siblings by specifying the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool or provide alternatives. Usage is implied by the required certificateId parameter and the tool's name, but no exclusions or when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the scope 'specific registered device' but does not elaborate on the return format or any side effects, which is acceptable given the low complexity and strong annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'Get detailed information about a specific registered device'. Every word contributes meaning, with no redundancy or filler.
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 simple read-only tool with one well-documented parameter and no output schema, the description sufficiently conveys its purpose. It could optionally detail what 'detailed information' includes, but given the low complexity and strong annotations, it is nearly complete.
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%—the single parameter 'deviceId' is clearly described as 'App Store Connect device ID'. The description doesn't need to add parameter details, and it doesn't, meeting the baseline for high 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?
The description 'Get detailed information about a specific registered device' uses a clear verb ('get') and resource ('device'), and distinguishes from sibling tools like 'list-devices' by emphasizing 'specific'. This clearly conveys a single-item lookup operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used when you need details on one device, as opposed to listing all devices (list-devices). However, it does not explicitly state when to use it versus alternatives or provide any exclusions, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds only the app-ID scoping constraint, not additional behavioral details like pagination or response shape; it does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that conveys the core purpose with no redundancy. Every word earns its place.
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 list operation, the description coupled with the detailed schema covers essential inputs and safety. It does not explicitly mention return shape, but 'List' and schema filters make the behavior sufficiently predictable.
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 coverage is 100%: all six parameters have descriptions, including the required appId and optional filters/limit. The description merely restates that lookup is by app ID, adding no further semantic value beyond the schema.
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?
The description uses the specific verb 'List' and names the resource 'App Store versions for an app (by app ID)', which clearly distinguishes it from siblings like get-app-store-version and create-app-store-version. The scope of the operation is immediately evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you have an app ID and need a list of its versions, but it does not explicitly state when to prefer this over get-app-store-version or mention exclusions/alternatives. The context is clear but not formally differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe read-only operation. The description adds context about the content (contact info, demo account, notes) but does not disclose any additional behavioral traits such as pagination, ordering, or detailed response structure. Moderate value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a front-loaded verb and object, no filler words, and just enough detail to understand the resource scope. It is appropriately sized.
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?
The tool is a simple read-only list with three parameters (all schema-described) and no output schema. The description covers the resource type and core purpose, while the schema covers parameter details. It could be slightly more complete by noting the distinction from 'list-beta-app-review-submissions', but the description is sufficient for correct invocation.
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%, with clear descriptions for all three parameters, including required 'filter.app' and default/max for 'limit'. The description's parenthetical content refers to the returned data, not the parameters, so it adds no meaningful parameter semantics beyond the schema.
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?
The description uses a specific verb 'List' and a precise resource 'TestFlight (beta) app review details' with helpful clarifying content in parentheses: '(contact info, demo account, notes)'. This makes it clearly distinct from siblings like 'list-beta-app-review-submissions'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: it lists beta app review details for a given app. However, there is no explicit statement of when to use this versus sibling list tools, nor any exclusions. The description would benefit from naming alternatives or stating that it returns review metadata rather than submissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as readOnly, idempotent, and non-destructive, covering the safety profile. The description adds minimal behavioral context (e.g., scoping to a build), but does not disclose pagination, response shape, or any operational nuances. It is consistent with annotations, and the extra context is thin but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy. Every word contributes to clarity, efficiently stating the verb, resource, and scope.
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?
Given the tool's simplicity, the description adequately conveys the core purpose. The schema provides full parameter details, and annotations cover safety. With no output schema, the description could mention what fields are returned, but for a list endpoint this is not a critical gap. The description is complete enough for an agent to select and invoke correctly.
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% for all three parameters, so the schema already explains limit, filter.build, and filter.betaReviewState. The description does not add any additional meaning beyond what the schema provides, matching the baseline for high 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?
The description clearly states the tool's function: listing TestFlight (beta) app review submissions for a specific build. It uses a specific verb ('List') and resource ('beta app review submissions') and distinguishes from sibling tools like list-review-submissions (general) and list-beta-app-review-details (details vs submissions).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for beta review submissions tied to a build, which provides clear context. However, it does not explicitly mention when to use this tool over alternatives like list-beta-app-review-details or list-review-submissions, nor does it state any exclusions or prerequisites beyond what the schema implies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, providing a strong safety profile. The description adds the scope detail 'internal and external', which is useful but minimal additional behavioral context; it does not disclose pagination or return structure beyond the word 'list'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler or redundant content. It efficiently communicates the tool's purpose.
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?
Given the strong annotations and 100% schema coverage, the description is mostly complete for a simple read-only list operation. However, it does not explicitly differentiate from the get-beta-group sibling or mention the filter capabilities, leaving a small gap in context.
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?
All four parameters have descriptions in the schema (100% coverage), so the schema fully explains limit and filter semantics. The description adds no additional parameter context, giving it the baseline score.
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?
The description clearly states the tool's function with a specific verb ('Get a list') and resource ('beta groups'), and further clarifies scope as 'all' and 'internal and external'. This effectively distinguishes it from single-group retrieval tools like get-beta-group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing all beta groups but provides no explicit guidance on when to use this tool versus alternatives such as get-beta-group or filtered listing via the schema's filter parameters. There are no exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description is not burdened with safety disclosure. It adds that filtering is optional, but does not describe default behavior (e.g., returns all testers when no filter is applied) or pagination, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the main action and a parenthetical for filters. There is no redundant information, making it highly scannable.
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 simple list tool with strong annotations and full schema coverage, the description is adequate. However, it does not mention that omitting filters returns all testers or that multiple filters can be combined, which would be useful but not critical given the schema.
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% for all 7 parameters, so the description adds little beyond restating that filtering by app or beta group is possible. It does not clarify parameter syntax or combinations beyond what the schema already provides.
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?
The description clearly states the verb 'Get a list' with the resource 'beta testers', which is specific and distinguishes it from the singular 'get-beta-tester' sibling. It also mentions optional filtering, adding useful context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a list operation but does not explicitly state when to use it versus alternatives like 'get-beta-tester' or 'list-beta-groups'. No exclusions or alternative names are mentioned, leaving the agent to infer based on the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds useful domain context (the specific fields returned) but does not disclose additional behaviors like pagination limits or response format. This matches the baseline for annotation-covered read tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is fully front-loaded, using parentheses to add clarifying detail without waste. It earns its place with specific detail types and a scope qualifier.
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?
The tool is a simple list operation with well-documented parameters and strong annotations. No output schema is present, but the description names the key data fields, providing enough context for basic use. It falls short of a 5 because it does not describe response structure or any edge-case behavior, but for this simple read-only tool it is largely sufficient.
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%, with each parameter (limit, filter.id, filter.build) already described in the schema. The description does not add extra parameter-level detail beyond what the schema provides, so the baseline score of 3 is appropriate.
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?
The description uses a specific verb ('List') and resource ('build beta details') with a clear scope ('TestFlight builds'). It enumerates specific detail types (export compliance, auto-notify, internal/external state), which distinguishes it from sibling 'list-builds' that lists builds without these details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context (TestFlight builds) but does not explicitly state when to use this tool over alternatives like list-builds. The mention of beta-specific fields is an implicit hint, but there is no explicit 'use this when' or 'not for that' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description only adds the scope 'in your team', which is minor behavioral context. It does not mention pagination or return format, but the bar is lower given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, front-loaded sentence with zero wasted words. It effectively communicates the core purpose without unnecessary elaboration.
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 simple list tool with good annotations and full schema documentation, the description provides sufficient context (team scope). It does not mention filter or limit capabilities, but these are documented in the schema. The absence of an output schema means the description need not explain return values. Slightly better than minimal given the scope clarification.
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% - every parameter has a description. The description adds no additional parameter information beyond what the schema provides. This earns the baseline score of 3, as the schema does the heavy lifting.
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?
The description uses a specific verb and resource: 'Get a list of signing certificates in your team'. It clearly states the action and scope, and the naming 'list-certificates' distinguishes it from related tools like get-certificate and other list-* siblings. It fully conveys the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need certificates from your team) but does not provide explicit guidance on when to prefer this over alternatives such as get-certificate (single cert) or list-profiles. No exclusions or alternative references are given, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful context by giving examples of nomination types, but does not mention any additional behavioral traits such as pagination or default filtering behavior beyond what the schema already specifies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence. It includes the primary purpose and clarifying examples without any fluff or repetition of schema details.
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 straightforward listing tool with good annotations and fully described parameters, the description is mostly complete. It does not describe the return format, but since no output schema is present, a brief mention of the returned list would be slightly better; however, the tool's simplicity and the clarity of purpose make this a minor gap.
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%, with each parameter (limit, filter.type, filter.state, filter.relatedApps) having clear descriptions in the schema. The tool description itself adds no parameter-specific semantics, but the schema fully covers parameter meaning, so baseline 3 is appropriate.
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?
The description clearly states the verb 'List' and the resource 'App Store nominations', with examples ('custom product pages, in-app events') that clarify the resource type. No sibling tool targets nominations, so this distinguishes itself from all other list-* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need to retrieve nominations but does not explicitly state when to use it over alternatives or provide exclusions. The listing context is clear enough for a simple read operation, but there is no explicit guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds TestFlight context and app scope but does not disclose additional behavioral traits like pagination, sorting, or response format. It provides minimal value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource. There is no redundancy or wasted words; every word contributes to understanding the tool's purpose.
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?
The tool is simple with 5 optional parameters well-documented in the schema and annotations covering the safety profile. The description is sufficient for a list operation, even without an output schema, though it could mention response behavior if warranted.
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 no additional parameter semantics beyond what the schema provides; the mention of 'app or across apps' aligns with filter.app but does not elaborate further.
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?
The description uses a specific verb ('List') and resource ('pre-release versions'), adding the TestFlight context and clarifying the scope ('for an app or across apps'). This clearly distinguishes it from sibling tools like get-pre-release-version and other list-* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the scope ('for an app or across apps') but does not explicitly state when to use this tool versus alternatives such as get-pre-release-version or other list tools. No exclusions or direct guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide a thorough safety profile (readOnlyHint, idempotentHint, destructiveHint, openWorldHint). The description adds no extra behavioral context such as pagination behavior, ordering, or rate limits. Credit is given for not contradicting annotations, but no additional disclosure is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that contains no redundant information. It is front-loaded with the action and resource, making it easy to parse quickly.
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 simple list tool with one optional parameter and rich annotations, the description is sufficient. It does not describe return format, but no output schema exists and the tool behavior is straightforward. Minor gap: no mention of whether results are paginated, but not critical for this context.
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?
The input schema fully describes the single parameter 'limit' with default and constraints. The description does not add any parametric meaning beyond what the schema provides, but with 100% schema coverage, the baseline of 3 is appropriate.
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?
The description clearly states the tool's purpose: 'Get the list of territories (countries/regions) for App Store availability.' It names the specific resource (territories) and the context (App Store availability), making it distinct from sibling tools like list-app-categories or list-builds. The verb 'Get' properly indicates a read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when needing territory/country lists for App Store availability) but does not explicitly state alternatives or exclusions. There is no mention of related tools or when not to use it. The usage context is clear but not fully elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat safety traits. However, the description adds no extra behavioral context such as pagination behavior, default limits, or that all users are returned unless filters are applied. It is a minimal statement that aligns with annotations, with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly conveys the purpose without unnecessary words. It is front-loaded with the action and resource, making it easy to scan and understand.
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?
Given the low complexity of the tool, the rich annotations, and complete parameter schema, the description is sufficient for an agent to understand what the tool does. While it does not mention return format or filtering behavior, the schema and annotations cover these aspects adequately. It is complete for a simple, read-only list operation.
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?
The input schema covers 100% of parameters with descriptive text (e.g., 'Maximum number of users to return', 'Filter by role(s)'). The description itself does not mention parameters or add semantic value beyond the schema. Baseline 3 is appropriate because the schema already provides adequate parameter information.
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?
The description clearly states the tool's function: 'Get a list of team members (users) in your App Store Connect team'. It uses a specific verb ('Get a list'), identifies the resource ('team members (users)'), and provides context ('App Store Connect team'). It distinguishes from siblings like 'list-user-invitations' by referring to 'team members' rather than invited users, and from 'get-user' by implying a list operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for listing active team members but does not explicitly state when to use it versus alternatives or any exclusions. It lacks guidance on using filtering parameters or when to prefer this over related tools like 'list-user-invitations' or 'get-user'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the useful behavioral detail that there is one agreement per app, but doesn't disclose additional behaviors like pagination or default limit, which schema hints at.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core purpose and immediately followed by a useful pointer to a sibling tool. No wasted words.
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 simple list operation with optional parameters, the description covers the core function and cardinality. It lacks parameter guidance, but the schema provides defaults/limits, and annotations cover safety, so it's largely complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with only filter.app described. The description adds no parameter information, leaving limit and filter.app semantics mostly to the schema. Since it doesn't compensate for the coverage gap, parameter understanding is weaker than it could be.
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?
The description clearly states the tool lists TestFlight (beta) license agreements, and adds 'One per app' for scope. It also distinguishes itself by pointing to get-beta-license-agreement for reading/updating text, making the purpose unambiguous among siblings.
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?
The description explicitly names an alternative tool for text operations, giving a clear when-to-use-this-other-tool signal. However, it doesn't fully elaborate on when to use this list tool over other list tools, though the verb 'List' implies listing all agreements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the scope 'in your team' but does not disclose additional behaviors like pagination, filtering, or response shape, which is acceptable given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource. It is appropriately sized for a straightforward list operation, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with robust schema and annotations, the description is minimally sufficient. It states the resource and scope but does not mention pagination limits or filter capabilities, though the schema covers those details. The absence of an output schema is not problematic for this basic listing operation.
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 input schema fully documents all five parameters (limit, filters for id, name, profileType, profileState). The description adds no parameter information, but this is not necessary because the schema carries the burden effectively.
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?
The description uses a specific verb 'Get a list' and clearly identifies the resource as 'provisioning profiles in your team'. It effectively distinguishes itself from sibling tools that list other resources like devices or certificates.
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?
The context for use is clear: to retrieve provisioning profiles. While no explicit exclusions or alternative tools are mentioned, the tool's purpose is unambiguous and no sibling tool lists profiles, so the intended usage is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations are all false, giving limited safety info (not read-only, not idempotent, not destructive). The description adds that existing EULA data can be changed and that the EULA ID must already exist, but it does not clarify whether omitted fields are preserved or whether territory IDs replace or append, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, with the main purpose front-loaded and the useful pointer to get-eula in the second sentence. Every word contributes, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema covers parameter meanings, the description lacks an explanation of the partial-update semantics (e.g., what happens to agreementText when omitted) and does not describe the return value, which is absent from the output schema. For a simple mutation tool, this leaves a small but noticeable gap.
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%, with each parameter documented (e.g., 'Omit to keep current' for territoryIds). The description's mention of 'text and/or territories' reinforces the optional parameters but adds no new semantics beyond the schema, so it meets the baseline.
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?
The description uses the verb 'Update' with the resource 'app EULA' and specifies the scope 'text and/or territories', clearly distinguishing this tool from read-oriented siblings like get-eula and from other update tools targeting different resources. The purpose is specific and unambiguous.
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?
It provides an explicit prerequisite by instructing to get the EULA ID from get-eula, which orients the agent to the correct data flow. However, it does not mention exclusions or alternative tools for related resources like beta license agreements, so it only partially covers usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare idempotentHint=true and destructiveHint=false, so the safety profile is clear. The description adds the prerequisite about sourcing IDs from list-beta-testers but does not elaborate on edge cases (e.g., duplicates, invalid groups). This is acceptable given annotations coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-formed sentence with an additional prerequisite note. Every word earns its place; no filler or redundant explanation.
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 simple two-parameter mutation with full schema coverage and clear safety annotations, the description is sufficiently complete. It states purpose and the source of IDs. It does not describe the return value, but no output schema exists and a success/failure response is typically implied.
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?
Input schema covers 100% of the parameters with descriptions. The tool description repeats the 'come from list-beta-testers' note already in the schema, adding no new semantic value beyond what the schema provides.
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?
The description clearly states the action ('Add one or more beta testers to a TestFlight group') with a specific verb and resource, and naturally distinguishes it from the sibling tool 'remove-beta-testers-from-group'.
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?
The description identifies the prerequisite that tester IDs come from 'list-beta-testers', implicitly guiding the user to that tool first. It does not explicitly exclude alternatives like 'remove-beta-testers-from-group', but the add/remove distinction is obvious from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide basic flags (readOnlyHint=false, destructiveHint=false), so the description carries some burden. It adds the behavioral constraint 'One response per review', which is useful context, but does not explain what happens if a response already exists, whether it replaces or errors, or any auth/rate-limit considerations. This is acceptable but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the core purpose and containing no filler. The constraint and pointer to the sibling tool are conveyed efficiently, demonstrating excellent conciseness.
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 simple two-parameter tool with no output schema and neutral annotations, the description covers the essential context: what it does, the one-response limitation, and how to obtain the required ID. It lacks detailed error/edge-case behavior, but given the tool's low complexity, this is sufficient.
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 coverage is 100%, with both parameters already described (customerReviewId from list-customer-reviews, responseBody visible to user). The description adds minimal parameter-specific value beyond the schema, mainly reinforcing the source of the review ID. Baseline 3 is appropriate as the schema handles the heavy lifting.
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?
The description uses a specific verb 'Reply' and resource 'App Store customer review', clearly distinguishing it from read-only siblings like list-customer-reviews. It also adds a key constraint (one response per review) and points to the prerequisite tool for obtaining review IDs, leaving no ambiguity about what the tool does.
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?
It explicitly instructs to use list-customer-reviews to get review IDs, establishing when this tool is appropriate. The 'One response per review' constraint helps the agent understand the operation's limits, though it does not name alternative tools or explicitly state when not to use it. This is clear context but lacks exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey mutation (readOnlyHint=false) and non-idempotency. The description adds the workflow context and notes productId is permanent, which is also in the schema. No extra behavioral traits beyond the annotations and schema are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and includes a useful workflow hint without any wasted words.
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?
Despite having 7 parameters and no output schema, the description covers the essential workflow and points to next steps. The schema handles parameter details, and the annotations cover safety. A bit more detail on return value or prerequisites could push it higher, but it's sufficiently complete for selection and invocation.
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 coverage is 100%, so the schema documents all parameters. The description only mentions productId and name as required, and the workflow hint about localizations/prices does not add semantic detail beyond what the schema already provides.
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?
The description clearly states the tool creates an auto-renewable subscription in a subscription group, using specific verbs and resources. It also distinguishes from sibling tools like create-subscription-group and create-subscription-localization by implying the primary creation step.
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?
The description provides clear workflow guidance: requires productId and name, then add localizations and prices with named sibling tools. It does not explicitly state prerequisites like needing an existing subscription group, but the schema and sibling context imply this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false) already indicate this is a write operation, and the description's 'create' aligns. However, the description adds no extra behavioral context such as side effects, permissions, or return values. It is not contradictory, but also not enriching beyond the obvious mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first defines the tool's purpose, the second gives a direct follow-up action. Every word earns its place; it is front-loaded with the core action and resource, with no unnecessary detail.
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 simple create operation with two fully documented required parameters and no output schema, the description is sufficient. It explains what a subscription group is and how to proceed, though it could mention what is returned. This is a minor gap, but overall it is complete for the tool's simplicity.
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?
The input schema provides full descriptions for both parameters (appId and referenceName), covering 100% of the schema. The tool description itself does not add any additional meaning about the parameters, so it stays at the baseline for high 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?
The description clearly states the tool creates a subscription group, explicitly defines it as a container for auto-renewable subscriptions, and differentiates from the sibling tool create-subscription by instructing to use that next. This provides a specific verb and resource, making the purpose unambiguous.
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?
The description gives a clear workflow: create the group first, then add subscriptions via create-subscription. This implies the appropriate usage context and distinguishes from alternatives, though it does not explicitly state when not to use the tool or mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds only a minor clarification ('territories where the app is available') without further behavioral details such as return format or pagination, which is adequate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose and followed by a useful pointer to a sibling tool. There is zero waste and every part adds value.
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 simple read-only tool with one parameter and no output schema, the description sufficiently conveys the tool's function and scope. It does not detail the return structure, but that is not strictly necessary given the simplicity of the operation and the existing schema.
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 coverage is 100% with the appId parameter already described as 'App ID. Availability defines which territories the app is in.' The description adds no new parameter meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
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?
The description clearly states the verb 'Get' and the resource 'app availability', and further clarifies it as 'territories where the app is available'. This distinguishes it from the sibling tool 'list-territories' by indicating a different focus.
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?
The description explicitly points to an alternative: 'Use list-territories for territory list'. This gives the agent a clear alternative when a list of all territories is needed, though it does not explicitly describe all scenarios for using this tool itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true, destructiveHint=false, idempotentHint=true) already cover the safety profile, and the description does not contradict them. It adds minimal behavioral context ('TestFlight') but no information about return behavior, permissions, or side effects, which is expected given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is concise and free of redundancy. It communicates the core function without waste.
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 simple read-only tool with one parameter and rich annotations, the description is adequate: it specifies the target resource and that it returns detailed info. However, it does not describe the return structure (no output schema) or that the ID comes from list-pre-release-versions, so it's not fully complete.
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 schema fully documents the single parameter 'preReleaseVersionId' as 'App Store Connect pre-release version ID'. The description adds no additional parameter meaning beyond that, so the baseline of 3 is appropriate.
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?
The description uses a specific verb ('Get') and resource ('pre-release (TestFlight) version'), clearly distinguishing this from sibling tools like list-pre-release-versions (which lists all) and get-build (which gets a build). It precisely states the tool's scope.
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?
The phrase 'a specific' implies the tool is used when you already have an identifier, which is clear context. However, it doesn't explicitly mention alternatives or exclude cases (e.g., 'to list versions, use list-pre-release-versions'), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds minimal behavioral context by mentioning the included relationships (state, items, app), but doesn't elaborate on response format or edge cases, which is acceptable given the annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with a front-loaded verb and object. It conveys the essential purpose without any fluff, and the parenthetical adds relevant detail without bloating the description.
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 simple get-by-ID tool with full schema coverage and comprehensive annotations, the description is adequate. It names the resource, the lookup key, and hints at return relationships, though it doesn't disambiguate from 'get-app-store-review-detail' or explain the submission lifecycle.
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?
Both parameters have schema descriptions (100% coverage), so the description doesn't need to add much. The phrase 'state, items, app' roughly aligns with the include parameter values, but adds no new syntax or semantics beyond what the schema already documents.
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?
Description uses specific verb 'Get' and resource 'single App Store review submission by ID', distinguishing it from list tools and beta-specific siblings. The parenthetical '(state, items, app, etc.)' adds clarity about the resource contents, making it clear this fetches one submission with its relationships.
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?
The phrase 'by ID' clearly indicates this tool is for retrieving a single known review submission, contrasting with listing tools in the sibling set. The ID parameter description 'from list-review-submissions' implies a workflow of listing first then fetching details. However, it doesn't explicitly name alternative tools for exclusion, so it earns a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the actor types (users or API keys) and the source of IDs, which is useful but does not disclose pagination behavior or return format. This is adequate but not rich, matching the baseline for annotation-covered tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise, front-loaded sentences. The first sentence states the purpose, and the second provides usage context. Every word earns its place, with no redundancy.
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?
Given the tool's simplicity (2 parameters, no output schema, strong annotations), the description is nearly complete. It covers purpose, usage context, and the source of IDs. It does not mention alternative tools or pagination, but those are not critical for this simple list tool. A score of 4 reflects the slight gap in not addressing the single-actor alternative (get-actor).
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 50%: filter.id has a description in the schema, while limit does not. The tool description reinforces the meaning of filter.id ('by ID(s)' and 'from review submissions or version history') but adds little about limit. The schema's default/min/max for limit provide some semantics. Overall, the description adds marginal value beyond the schema, so a baseline 3 is appropriate.
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?
The description clearly states the tool's function: 'List actors (users or API keys) by ID(s).' This specifies a verb, resource, and scope. It also distinguishes from siblings like 'get-actor' by indicating batch retrieval via plural 'actors' and 'by ID(s)', and clarifies the actor types.
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?
The description gives explicit context: 'Use when you have actor IDs from review submissions or version history.' This tells the agent when to use the tool. However, it does not name alternatives or provide 'when not to use' guidance, so it falls short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds contextual detail about the type of data returned (feedback email, marketing URL, description per locale). However, it doesn't disclose pagination behavior or return format, though the schema's limit parameter partially addresses this. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the main action and resource, followed by a concise parenthetical clarifying the content. It is appropriately sized with no wasted words.
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 simple list tool with detailed schema and annotations, the description provides enough context: it identifies the resource and the type of localized content. It doesn't explicitly mention that it lists all localizations across apps, but the tool name and filter parameters imply this. No output schema exists, but the description covers the return content sufficiently.
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 does not add parameter-specific information beyond the schema, but the schema already provides clear descriptions for limit and filters. The parenthetical in the description gives context for what the localizations contain, which relates to the overall purpose more than individual parameters.
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?
The description clearly states the tool lists TestFlight (beta) app localizations and specifies the content (feedback email, marketing URL, description per locale). This provides a specific verb and resource, and effectively distinguishes it from sibling tools like list-beta-app-review-details.
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?
The description implies the tool is for listing beta app localizations, which is clear from the context. It does not explicitly mention when to use it over alternatives, but no alternatives are needed given the unique purpose. The clarity of the verb and resource provides sufficient usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the project/workspace scope but does not disclose return format, error behavior, or edge cases like empty scheme lists, which is acceptable given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, compact sentence that is front-loaded with the core purpose. Every word is informative; no filler or repetition of the title.
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?
Given the low complexity (one well-documented parameter, no output schema), the description is sufficiently complete to let an agent invoke the tool correctly. It would ideally mention that the return is a list of scheme names, but that is strongly implied by the phrase 'list all available schemes'.
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?
The schema description for 'projectPath' is clear and 100% coverage, so the description has no additional parameter burden. It does reinforce the parameter meaning by mentioning 'project or workspace', but adds no new syntactic or format details beyond the schema.
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?
The description clearly states the action ('list'), the resource ('schemes'), and the scope ('Xcode project or workspace'). This distinguishes it from all sibling tools, which are focused on App Store Connect APIs and none mention Xcode schemes.
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?
The context of use is clear: when you need to enumerate schemes in an Xcode project or workspace. No alternatives are mentioned, but given the sibling list, there are no overlapping tools, so explicit exclusions are unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the context that returned IDs are intended for use with specific sibling tools, but does not disclose additional behavioral traits like pagination or error handling. Since annotations carry the safety profile, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no unnecessary content. It is front-loaded with the primary action and immediately provides actionable follow-up instructions. Every sentence earns its place.
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?
Given the tool's simplicity (3 params, 1 required), good annotations, and no output schema, the description is sufficiently complete. It clarifies the purpose and gives next steps, but could have mentioned filtering capabilities; however, the schema covers that. Overall, it is adequate for a list tool.
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%, with each parameter described adequately (appId, limit, filter.referenceName). The description itself adds no parameter-specific meaning beyond what the schema already provides, so the baseline of 3 is correct.
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?
The description clearly states the tool's function with a specific verb and resource: 'List subscription groups for an app.' It also distinguishes itself from siblings by mentioning how the returned group IDs are used with list-subscription-group-subscriptions or create-subscription, which adds purpose clarity.
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?
The description gives explicit context for use: it lists subscription groups for an app and directs the user to follow up with returned IDs in other tools. It does not explicitly exclude alternatives, but the 'for an app' scope and next-step guidance imply appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that it lists auto-renewable subscriptions and returns fields like productId, name, state, prices, but does not disclose pagination or rate limits; this is adequate given annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with front-loaded purpose and no filler. Every sentence earns its place.
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 list tool with a rich schema and read-only annotations, the description is complete enough. It briefly summarizes return fields since no output schema exists, and the schema covers parameter details.
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 coverage is 100%, so all parameters are already documented. The description only adds example product IDs, which is marginal beyond the schema, so the baseline score of 3 applies.
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?
The description clearly states that the tool lists auto-renewable subscriptions within a subscription group, naming the resource and scope. It distinguishes from siblings like list-subscription-groups (which lists groups) and get-subscription (single subscription).
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?
Provides a clear use case ('verify products like premium_monthly_v2 and premium_annual_v2 in a group') but does not explicitly exclude alternatives or name sibling tools as alternatives. The context is clear, but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds the downstream usage but discloses no additional behavioral traits beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and contains no wasted words. It is concise and well-structured.
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?
The description is sufficient for a simple list operation with annotated hints and complete schema. It mentions the returned price point id, providing useful context, though it does not describe the full return shape.
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 coverage is 100%, with each parameter having a description. The tool description adds no extra parameter meaning, so it meets the baseline for high 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?
The description clearly states the tool lists price points for a subscription, using a specific verb and resource. It also distinguishes this from sibling tools by specifying the downstream use case with create-subscription-price.
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?
The description provides clear usage context by noting the returned price point id should be used in create-subscription-price. It gives a specific workflow hint but does not explicitly mention alternatives or when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds a minor usage tip about sourcing IDs from list-beta-testers but does not elaborate on side effects, error behavior, or permissions. With annotations carrying the main burden, the description adds limited additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and contains no redundant information. It efficiently communicates the operation and a key usage note.
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 simple removal tool with two fully described parameters and no output schema, the description is sufficient. It explains the operation and where to obtain the necessary IDs. It does not mention error cases or response format, but these are not required given the tool's simplicity and the annotations.
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 coverage is 100%; both betaGroupId and betaTesterIds are described clearly in the schema. The description reiterates the source for tester IDs but does not add meaning beyond what the schema already provides. Baseline of 3 is appropriate.
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?
The description clearly states the action 'Remove one or more beta testers from a TestFlight group,' which is a specific verb, resource, and object. It distinguishes itself from sibling tools like add-beta-testers-to-group and list-beta-testers by its purpose.
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?
The description provides clear usage context by indicating the operation targets a TestFlight group and specifies that tester IDs must come from list-beta-testers, which serves as a prerequisite. It does not explicitly exclude alternatives, but the sibling naming and verb make the use case obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is not read-only, not idempotent, and not destructive. The description adds useful context by detailing the exact sequence of operations (create, add, mark submitted), which goes beyond the structured annotations. However, it does not disclose potential side effects like irreversibility or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and immediately explains the three-step process. Every phrase earns its place, with no fluff or redundancy.
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?
With three parameters, no output schema, and all annotations false, the description covers the essential behavior (submitting a version) and its immediate effects. It does not elaborate on edge cases, prerequisites, or expected response, but for a straightforward submission action, the description is sufficient.
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?
The input schema already has 100% parameter description coverage, and the description does not add meaningful semantic information beyond what is already in the schema. The description's mention of 'adds the version as an item' aligns with appStoreVersionId, but the schema itself already documents all required/optional parameters adequately.
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?
The description explicitly states the action ('Submit an App Store version for review') and outlines the steps involved ('Creates a review submission, adds the version as an item, and marks it as submitted'). This clearly differentiates it from sibling tools that list, get, or update review submissions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context (when you want to submit a version for review) but does not provide explicit guidance on when to prefer this tool over alternatives, nor does it mention prerequisites or exclusions. The unique verb 'submit' among siblings provides some implicit differentiation, but no direct comparisons are made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds the context that the update is a prerequisite for external testing but does not disclose side effects, reversibility, or authorization requirements beyond what the annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two short sentences front-loading the action and resource. Every word serves a purpose, making it easy to scan.
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 simple two-parameter update tool with no output schema, the description provides sufficient context along with the schema. It explains the purpose and requirement for external testing, but it doesn't detail the response format. Given the low complexity, this is adequate.
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?
Both parameters are fully described in the input schema (100% coverage), and the description does not add any additional parameter-specific information. It only mentions the resource being updated, so it does not exceed the schema's baseline.
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?
The description uses the specific verb 'Update' with the resource 'TestFlight (beta) license agreement text', clearly distinguishing it from sibling tools like get-beta-license-agreement or list-beta-license-agreements. The additional context 'Required for external testing' further clarifies its role.
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?
The description states when this update is needed ('Required for external testing'), providing a clear use case. However, it does not mention alternatives or when not to use it, so it only partially meets the criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior. The description adds value by specifying the kind of information returned (metadata, state, build link), which is especially helpful given the absence of an output schema. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It directly states the action, resource, and key details, making it highly concise and well-structured.
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?
For a simple one-parameter read tool with strong annotations (readOnly, idempotent, non-destructive), the description is complete enough. It covers the purpose and gives a sense of the return content (metadata, state, build link), which is essential since no output schema exists. The tool's simplicity means no further context is required.
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?
The schema fully describes the only parameter 'appStoreVersionId' as an 'App Store Connect app store version ID', giving 100% coverage. The tool description does not add extra semantic detail beyond that, so the baseline score of 3 is appropriate.
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?
The verb 'Get' clearly indicates a retrieval operation, and the resource is 'a specific App Store version', distinguishing it from the sibling 'list-app-store-versions' which handles multiple versions. The parenthetical '(metadata, state, build link)' adds specificity about what 'detailed information' includes, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need details for a single version (by ID), but it does not explicitly state when to use this tool over the list or update siblings. It lacks direct alternatives or exclusions, so the usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds useful detail about the response content (fields included), but does not disclose other behaviors such as error handling or not-found scenarios. This adds some value but is not extensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and scope, listing a few illustrative fields without verbosity. Every word contributes to clarity.
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?
This is a simple, single-parameter read tool with strong annotations and a clear sibling context. The description gives enough detail about return content to allow correct invocation, and the output schema is not needed given the straightforward nature.
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?
The schema fully documents the single parameter with a description ('Subscription ID...'), giving 100% coverage. The tool description does not add further parameter semantics, so the baseline of 3 applies—the schema carries the load.
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?
The description uses a specific verb ('Get') with a clear resource ('one subscription by ID') and enumerates the returned fields (productId, name, state, prices, etc.). This clearly distinguishes it from the sibling list tool, which retrieves multiple subscriptions.
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?
The description implies the tool is for fetching a single subscription when the ID is known, which gives clear context. However, it does not explicitly name alternatives like the sibling list-subscription-group-subscriptions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is a write operation (readOnlyHint=false) and not destructive. The description adds process-level context ('Required before submit for review') but does not disclose other behavioral traits such as overwriting behavior, idempotency, or permission requirements. Since annotations cover basic safety profile, the description adds some value but not deeply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and every clause serves a purpose. It is efficient and free of irrelevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters and no output schema, the description explains the 'why' (required before submit) and the 'what' (fields to update), but it does not state what the tool returns, which is common for update tools. The workflow hint compensates somewhat, but the absence of any return behavior leaves a gap.
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?
The input schema covers all 9 parameters with descriptions, so baseline is 3. The description groups parameters into 'contact, demo account, notes,' which provides a high-level conceptual mapping but does not add any syntax or format details beyond the schema. This is acceptable but not additive.
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?
The description clearly states the action: 'Update App Review details for a version: contact, demo account, notes.' This uses a specific verb ('Update') and resource ('App Review details'), and lists the key fields, which distinguishes it from the sibling read tool 'get-app-store-review-detail' and from 'submit-for-review'.
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?
The description explicitly provides a usage condition: 'Required before submit for review if app needs login or special instructions.' This tells the agent when in the workflow to use the tool and implies when it may not be needed, offering clear context without needing to name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read, non-idempotent operation. The description adds the important behavioral constraint that the version must be approved or in release, and explains the meaning as gradual rollout. It is consistent with annotations, though it does not detail state transitions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no wasted words. It front-loads the action and resource, then adds a necessary condition. Every word earns its place.
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 two-parameter tool without an output schema, the description conveys the core behavior and prerequisite. It does not explain return values, but that is not critical for invocation, and the schema covers the parameters.
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?
The input schema already provides descriptions for both parameters with 100% coverage. The tool description does not add extra meaning beyond the schema, so it meets the baseline.
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?
The description clearly states the action ('Enable') and the resource ('phased release for an App Store version'), with a clarifying parenthetical ('gradual rollout to users'). It is specific and distinguishes the tool from read-only siblings like get-phased-release.
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?
It provides an explicit precondition ('Version must be approved or already in release'), which tells the agent when it is valid to use the tool. It does not explicitly name alternatives or exclusions, but the precondition scopes usage effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false). The description adds behavioral context beyond annotations by noting the per-locale uniqueness constraint ('Add one per locale') and the consequential requirement ('Required for submission'). It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, immediately starting with the action verb, with no redundant phrasing. Every word contributes to the purpose and context.
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 simple 4-parameter create tool with no output schema, the description covers the essential 'what', 'when' (per locale), and 'why' (required for submission). It lacks detail on response format or error conditions, but these are not critical for selection. Overall, adequately complete.
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 coverage is 100%, so the baseline is 3. The description does not add substantial meaning beyond the schema; it loosely references 'name/description' and 'locale' but does not provide new format, syntax, or relationship details.
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?
The description uses the specific verb 'Create' with the resource 'localized name/description for a subscription', which clearly distinguishes it from sibling tools like create-subscription or create-subscription-price. It also adds the constraint 'Add one per locale', further clarifying the tool's specific scope.
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?
The description provides clear context by stating 'Add one per locale' and 'Required for submission', indicating when and why to use the tool. However, it does not explicitly mention alternatives or exclusions, so it falls short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive. Description adds behavioral context by noting the report is gzip compressed and returns decompressed tab-delimited text, which is not conveyed by 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that immediately state the action, resource, format, and key prerequisite. No filler or repetition of schema details.
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?
With a rich schema and good annotations, description covers the return format and a necessary requirement. It lacks nothing critical for selection or invocation, though could mention alternative report types.
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 covers all 6 parameters with detailed descriptions (100% coverage). The description itself does not add parameter-level meaning beyond what schema already provides, so baseline 3 is appropriate.
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?
Description clearly states the action ('Download') and resource ('sales and trends report'), with format ('gzip TSV') and differentiates from sibling download-finance-report by specifying 'sales'.
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?
Provides clear context: requires APP_STORE_CONNECT_VENDOR_NUMBER. However, it does not explicitly contrast with download-finance-report or state when not to use, so lacks explicit alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read nature is covered. The description adds valuable behavioral context beyond annotations: the 404 response when no phased release exists, which is a meaningful edge case for an agent to handle. This qualifies as useful behavioral transparency without redundancy.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and highly efficient. The first sentence states the core action, and the second provides the critical edge-case behavior. No redundant information or fluff is present, making it easy for an agent to parse and retain.
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 simple single-parameter getter with no output schema, the description is sufficiently complete: it explains what is returned (the gradual rollout state) and a key edge case (404). While it does not enumerate response fields, this is often unnecessary for a getter, and the annotations cover the operational context. Slight room for improvement would be to explicitly mention the response shape, but the current description is adequate.
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?
The schema description for appStoreVersionId is already informative ('App Store version ID. Phased release is optional per version.'). The tool description reiterates the optional nature by mentioning 'Returns 404 if version has no phased release,' adding slight context about the parameter's effect on the outcome. However, since schema coverage is 100% and the description does not introduce new parameter meaning, a baseline score of 3 is appropriate.
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?
The description clearly states the tool's purpose: 'Get phased release for an App Store version (gradual rollout state).' It identifies the specific resource (phased release), the operation (get), and the scope (App Store version), distinguishing it from sibling get/list tools and the create-phased-release tool. The parenthetical '(gradual rollout state)' clarifies the domain concept.
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?
The description provides clear context for use: it retrieves the phased release for a given App Store version. It also indicates a key behavioral condition: 'Returns 404 if version has no phased release,' which implies that callers should check for this case or use create-phased-release if needed. However, it does not explicitly mention alternatives or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context that the return is 'metadata per locale', which is helpful beyond annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that starts with the action and resource, with a concise parenthetical clarification. There is no unnecessary verbosity.
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 simple list operation with rich annotations and fully described parameters, the description sufficiently orients the agent. The parenthetical gives a hint about return content. It doesn't mention pagination or filtering specifics, but those are in the schema, so this is adequate.
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%, with each parameter (limit, filter.locale, appStoreVersionId) described. The description adds no additional parameter meaning, so the baseline of 3 applies.
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?
Description clearly states the verb 'List' and the specific resource 'localizations for a specific App Store version', which distinguishes it from sibling tools like list-app-store-versions (lists versions) and update-app-store-version-localization (updates localizations). The parenthetical 'metadata per locale' adds useful scoping.
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?
The phrase 'for a specific App Store version' implies the agent needs an appStoreVersionId and should use this tool when targeting one version. However, it doesn't explicitly mention alternatives or when not to use it, though the sibling context helps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a non-read-only, non-idempotent mutation, and the description does not contradict this. The description adds context about what is updated (localized metadata) and points to a prerequisite, but it does not disclose side effects, permissions, or response behavior beyond the annotation flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences are used with the action and resource front-loaded, followed by an essential instruction. Every word earns its place with no redundant content.
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 7-parameter mutation tool with no output schema and limited annotations, the description covers the core operation and the source of the required ID. The absence of return-value details is a minor gap, but the full schema coverage and basic behavioral context make it sufficient.
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% with descriptions for all 7 parameters, setting a baseline of 3. The description adds value by telling where to get the required 'appStoreVersionLocalizationId' and summarizing the updateable fields, which goes slightly beyond the schema.
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?
The description uses a specific verb ('Update') with a clear resource ('app store version localization') and lists exact fields (description, keywords, URLs, what's new, promotional text). It distinguishes itself from sibling tools like 'update-app-store-version' by explicitly focusing on locale-specific metadata.
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?
Provides clear context: it updates localized metadata for a specific App Store version locale, and instructs the agent to obtain the localization ID from 'list-app-store-version-localizations'. However, it does not explicitly state when not to use this tool or mention alternatives, so it lacks full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation as read-only, idempotent, and non-destructive. The description adds value by disclosing the specific data fields returned (age rating, category, app store state) and reinforcing that results are territory-specific, which goes beyond the schema. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and includes a crucial cross-reference to 'list-app-infos' without any fluff. Every word earns its place.
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?
For a simple, one-parameter read operation with no output schema, the description fully covers what the tool does, what data it returns, and how to obtain the necessary ID. It is complete in context.
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?
The single parameter 'appInfoId' is fully described in the schema itself, including its origin ('from list-app-infos') and cardinality ('one per territory'). The tool description repeats this same information, adding no additional semantic value beyond the schema's coverage of 100%.
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?
The description clearly states the action ('Get'), the resource ('app info'), and the specific scope ('for one territory') while listing the key data fields (age rating, category, app store state). It also distinguishes itself from the broader sibling 'get-app' by emphasizing the territory-specific scope and referencing 'list-app-infos' as the ID source.
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?
The description provides clear context: this tool retrieves app info for a single territory, and IDs come from 'list-app-infos'. It implies a workflow dependency (call list-app-infos first) and implicitly differentiates from other get/list tools by scope, though it doesn't explicitly state when not to use it or name an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the returned data fields and the per-version scoping, plus a workflow note that these fields must be set before review submission. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that names the action, resource, and key details. It avoids redundancy and is appropriately sized for the tool's simplicity.
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?
The tool has one parameter, strong annotations, and no output schema. The description sufficiently covers what will be returned (contact info, demo account, notes) and when it is relevant (before submission), making it complete for this simple getter.
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%, and the parameter description already explains that review detail is per version. The tool description adds no extra parameter-level semantics beyond restating the resource context, so baseline 3 is appropriate.
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?
The description clearly states the action (get) and the resource (App Review details for an App Store version), and lists specific fields (contact info, demo account, notes for reviewers). It distinguishes from siblings like update-app-store-review-detail (write operation) and list-beta-app-review-details (beta context).
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?
The phrase 'Set these before submitting for review' provides a clear workflow context: use this tool to view the current review details before updating or submitting. It doesn't explicitly mention alternatives or exclusions, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint, idempotentHint, and destructiveHint=false, covering safety. The description adds the scoping to an app store version and the returned fields (rating, title, body, response), which provides useful behavioral context without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the main purpose and key details, with no wasted words.
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?
For a simple read-only list operation with fully documented parameters and no output schema, the description provides sufficient context: it names the resource, scope, and return fields. Sibling tools are clearly differentiated by the 'App Store' qualifier.
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 schema fully documents all parameters. The description does not add extra parameter semantics beyond what is already present, but it doesn't need to; the baseline of 3 is appropriate.
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?
The description clearly states the tool lists App Store customer reviews for a specific app store version, and it specifies the data fields returned (rating, title, body, response). This distinguishes it from sibling tools like list-beta-app-review-details and create-customer-review-response.
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?
The description indicates the tool is scoped to an app store version and that the ID comes from list-app-store-versions or get-app, which provides context for when to use it. However, it does not explicitly state when not to use it or mention alternatives, so it doesn't fully meet the top bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations do not indicate readOnly or destructive hints, so the description adds value by revealing the dependency on create-subscription-price and the specific 409 error consequence. It does not mention idempotency or other side effects, but the provided context is meaningful beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose and immediately followed by critical usage guidance. No wasted words.
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?
The tool is simple (3 params, no output schema) and the description covers the essential ordering constraint. The availabilityInNewTerritories parameter is documented in the schema, so the description need not repeat it. The context is complete for correct invocation.
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 itself does not elaborate on parameters beyond what the schema already includes; the schema's 'territoryIds' description already mentions list-territories and the relationship to create-subscription-price. No additional parameter insight is provided.
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?
The description opens with a specific verb and resource: 'Set which territories the subscription is available in.' This clearly distinguishes it from sibling tools like create-subscription-price and create-subscription, while also noting a critical relationship to create-subscription-price.
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?
Explicit usage guidance is provided: 'Call this before create-subscription-price; otherwise adding a price often returns 409 ENTITY_ERROR.RELATIONSHIP.INVALID.' This tells the agent when to use it, the ordering requirement, and a concrete failure mode if not followed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the tool as read-only, idempotent, and non-destructive. The description adds useful behavioral context by noting that results are one per territory and that it returns age rating, store state, and category. No contradictions, and the additional detail goes beyond the annotations without over-explaining.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences. The first states the operation and scope; the second gives an alternative tool. There is no redundant wording or repetition of schema details, making it highly efficient.
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 simple list tool with strong annotations and complete schema parameter descriptions, the description covers the essential semantics: what is listed, the per-territory scoping, and the alternative for single-territory use. It does not mention the limit's effect on pagination or ordering, but these are either in the schema or not critical for correct invocation.
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?
The input schema provides full descriptions for both parameters (appId and limit), including the territory note for appId and the range/default for limit. The description's 'one per territory' phrase reinforces the appId semantics but adds no new parameter-level detail beyond the schema, so the baseline of 3 is appropriate.
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?
The description clearly identifies the action ('List'), the resource ('app infos'), and the scope ('for an app' and 'one per territory'). It also enumerates key fields returned (age rating, app store state, category), and explicitly distinguishes it from 'get-app-info' for single-territory lookups.
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?
The description provides explicit usage guidance: it tells the agent to use 'get-app-info' for a single territory, thereby defining when this tool is appropriate (when you need per-territory app infos for an app). This is a clear alternative and contextual distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds a key behavioral limitation: the rejection message is not returned by the API and must be accessed via App Store Connect. It also clarifies that the tool returns historical submissions. This goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main action and scope. Each sentence earns its place: purpose, filtering with an example, and an important limitation. There is no fluff or redundancy.
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?
Despite lacking an output schema, the description covers the core purpose, filtering options, and a major data limitation. The limit and platform parameters are documented in the schema, and the required filter.app is implied by 'for an app'. It could mention ordering or response structure, but for a list tool with strong annotations, this is sufficient and only slightly below the highest bar.
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 description coverage is 100%, so the baseline is 3. The description adds value by explaining that filter.state uses UNRESOLVED_ISSUES for 'rejected' submissions, which is not obvious from the enum values alone. This directly enriches the meaning of a parameter, justifying a score above baseline.
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?
The description clearly states the verb and resource: 'List App Store review submissions for an app (submission history).' The parenthetical 'submission history' distinguishes this from current reviews or beta submissions, and the explicit 'App Store' differentiates it from sibling tools like list-beta-app-review-submissions. This is a specific, well-scoped purpose.
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?
The description provides clear context: listing submission history, filtering by state, and includes an example ('UNRESOLVED_ISSUES for rejected'). It also gives a when-not-to-use hint by noting the rejection message is not available via the API and points the user to App Store Connect. However, it does not explicitly name an alternative tool or enumerate conditions for when to choose a sibling, so it stops just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a mutation (readOnlyHint=false). The description adds valuable behavioral context by disclosing the 409 ENTITY_ERROR.RELATIONSHIP.INVALID error when availability is not set, which is beyond the annotation's boolean hints. It does not contradict annotations and makes the failure mode predictable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each with a distinct purpose: stating the core operation, warning about a prerequisite, and providing ID sourcing guidance. Every sentence earns its place with no redundancy or filler.
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?
The description covers the critical dependency (availability), a specific error code, and valid ID sourcing, which are essential for correct use. Without an output schema, it doesn't detail the response shape, but for a create operation with well-documented parameters and annotations, the provided context is sufficient and complete.
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 description coverage is 100%, so the baseline is 3. The description adds cross-tool semantics for territoryId, explaining it must match the filter.territory used in list-subscription-price-points, and clarifies the 'optionally territory' scope. This enriches the parameter meaning beyond the schema's individual field descriptions.
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?
The description opens with 'Attach a price to a subscription', a specific verb-resource pair that clearly states the tool's function. It further distinguishes itself from sibling tools like create-subscription-availability and list-subscription-price-points by explicitly referencing them as prerequisites, making the purpose unambiguous.
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?
The description provides explicit guidance on when to use this tool: after setting subscription availability, warning that a 409 error occurs otherwise. It also names the specific sibling tool create-subscription-availability for that prerequisite step and instructs using list-subscription-price-points for valid IDs, including the territoryId matching requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description doesn't repeat those. However, it adds valuable context about the return payload ('Returns agreement text and territory') and the data model ('EULA is one per app (with optional territory variants)'), which are not present in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, then return details and an alternative path. Every word earns its place, with no verbose filler or redundancy.
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 simple get tool with one parameter, strong annotations, and no output schema, the description covers the purpose, return content, and the alternative mutation path. It notes the territory nuance, though it could clarify how to request a specific variant if needed, hence not a 5.
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?
The appId parameter is fully described in the schema (100% coverage). The description adds extra meaning by explaining that the EULA is 'one per app (with optional territory variants)', which clarifies the relationship between the parameter and the resource, going beyond a simple field label.
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?
The description clearly states the tool's function: 'Get End User License Agreement (EULA) for an app.' It also identifies the return value ('Returns agreement text and territory'), making the purpose unambiguous. This distinguishes it from sibling update tools like update-eula.
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?
The description explicitly provides an alternative for write operations: 'Create/update via update-eula or App Store Connect UI.' This tells the agent when to use this read-only tool versus the mutation counterpart, satisfying the when/when-not requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![appstore-connect-mcp MCP server](https://glama.ai/mcp/servers/beautyfree/appstore-connect-mcp/badges/card.svg)](https://glama.ai/mcp/servers/beautyfree/appstore-connect-mcp)

Score Badge

Copy to your README.md:

[![appstore-connect-mcp MCP server](https://glama.ai/mcp/servers/beautyfree/appstore-connect-mcp/badges/score.svg)](https://glama.ai/mcp/servers/beautyfree/appstore-connect-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/beautyfree/appstore-connect-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server