App Store Connect MCP Server
Server Quality Checklist
Latest release: v0.1.1
- Disambiguation5/5
Each tool targets a distinct resource-action pair, with clear separation between apps, versions, builds, beta groups, IAPs, subscriptions, product pages, and experiments. Even similar-sounding tools like list_subscription_groups vs list_subscriptions are unambiguously differentiated by their resource focus.
Naming Consistency4/5Tool names generally follow a consistent verb_noun pattern (e.g., list_apps, get_build, create_iap). Minor deviations exist such as 'set_iap_price' vs 'update_iap' and 'submit_for_review' vs 'submit_iap_for_review', but these do not significantly hinder predictability.
Tool Count2/5With 45 tools, the server is heavily over-scoped for an agent to navigate effectively. Many tools could be consolidated (e.g., update_app_description, update_whats_new, update_keywords could be a single update_localization tool), making this count more appropriate for a library than an MCP server.
Completeness3/5The tool set covers a wide range of App Store Connect functionality, but gaps remain: no creation/deletion for beta groups, no update/delete for subscription offers, no delete for experiments, and no app version management beyond listing. These missing lifecycle operations create workflow dead ends.
Average 3.5/5 across 45 of 45 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues 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.jsonto 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
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It fails to mention whether updates are partial, how omitted fields are handled, or any side effects on pricing/localizations. The description provides zero transparency beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant wording. However, it lacks structure (e.g., bullets or sections) and is extremely brief, though this does not harm its efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 5 parameters and no output schema, this description is critically underspecified. It does not clarify the scope of updates, required fields beyond subscriptionId, or return behavior. The agent is left with insufficient information to use the tool safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter (name, groupLevel, reviewNote, familySharable, subscriptionId) fully described in the schema. The tool description adds no extra parameter semantics, so the baseline of 3 is appropriate since the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('update') and resource ('existing subscription'), distinguishing it from create_subscription or list_subscriptions. However, it does not differentiate from other update tools like set_subscription_price or set_subscription_localization, and it lacks specific details about what fields can be updated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as set_subscription_price or set_subscription_localization. It neither states prerequisites nor exclusions, leaving the agent to infer usage 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.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it provides almost none. It merely restates the action (starting an experiment) without mentioning side effects like making the experiment live to users, requiring a draft state, or irreversibility. This is essentially a tautology of the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, directly front-loaded sentence with zero fluff. It is concise, though slightly under-specified, which keeps it from a perfect 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that mutates experiment state, the description is incomplete. It does not explain prerequisites (e.g., the experiment must exist and be in draft), what happens on success, or how it relates to create_experiment and stop_experiment. The simple one-parameter schema mitigates the issue, but critical contextual information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single required parameter (experimentId) with a clear description. The tool description adds no additional parameter meaning, 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Start running') and the resource ('an A/B test experiment'), which distinguishes it from sibling tools like create_experiment and stop_experiment. However, it does not explicitly elaborate on what 'start running' entails (e.g., activation versus scheduling), leaving a slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. It does not mention that this should follow create_experiment or precede get_experiment_results, nor does it warn against using it on an already-running experiment. The intended workflow is only weakly implied by the tool name.
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?
With no annotations available, the description carries full responsibility for behavioral disclosure. It only says 'Update the keywords,' but does not mention whether existing keywords are replaced, whether any validation is performed, or what side effects occur. It also fails to state any authentication 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no unnecessary words, which earns it a middle score. However, it is under-specified: it does not explain the parameter relationships or the behavior beyond the bare action. It is concise but lacks the detail needed for full clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with two required parameters and no output schema, but the description still feels incomplete. It does not address the need to have an existing localization, the replace-vs-merge semantics, or how this relates to the broader app store localization workflow. Given the absence of annotations, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (localizationId and keywords), achieving 100% schema coverage. The description adds no extra meaning beyond what the schema offers, 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Update') and the target ('keywords') along with a scope ('for a specific locale'). It distinguishes from siblings like update_app_description and update_whats_new by naming the specific resource. However, it does not explicitly state that it operates on an app store version localization, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. Siblings such as update_app_description and update_whats_new exist for other fields, but the description does not indicate the appropriate context for choosing this one. The intended use is only implied by the name and brief description.
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?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action. It does not mention whether the operation is idempotent, required permissions, or behavior on duplicate referenceName.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no unnecessary words. It directly conveys the core purpose without elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with no annotations or output schema, the description is too minimal. It lacks context about what a subscription group is, any prerequisites, or potential side effects, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage of parameter descriptions, so the description adds no additional semantic value. The baseline of 3 is appropriate because the schema already documents the parameters clearly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('subscription group') with the context ('for an app'). It distinguishes the tool from siblings by the specific resource type, though it does not explicitly contrast it with create_subscription.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, prerequisites, or typical use cases. The description only states what it does, not when it should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states the core action and does not add any context about response format, required permissions, rate limits, or side effects. This is essentially a restatement of the tool's name and adds no transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the purpose without any wasted words. It is appropriately concise for a simple get operation, though it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is too sparse. It does not explain what 'details' are returned, nor does it provide any usage context. The single parameter is well-schema'd, but the agent lacks information about return values or any prerequisites, making the description incomplete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single parameter 'buildId' with its description 'The build ID'. The tool description does not add further semantic meaning, but the schema is sufficient, so the baseline of 3 applies. No additional nuances like parameter formatting or constraints are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get details') and the specific resource ('a specific build'), which distinguishes it from the sibling tool 'list_builds' that enumerates builds. The use of 'specific' implies a singular build identified by an ID, 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 Guidelines2/5Does 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_builds' or other get tools. It does not explicitly mention prerequisites (e.g., needing a buildId) or mention any exclusions, so the agent is left to infer usage from 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It only states 'Set a price point,' which implies a mutation but does not mention side effects like replacing existing price points, whether startDate can be immediate, or any required prior setup. This is minimal disclosure for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, fully front-loaded with the action and object. It contains no wasted words. However, it is so brief that it leans toward under-specification, preventing a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters including a nullable startDate), no annotations, and no output schema, the description is insufficient on its own. It does not explain the concept of price points, when the price takes effect, or how this relates to subscription groups or other subscription operations. An agent would need to infer much from the schema and sibling tool context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter clearly documented (e.g., startDate, pricePointId, subscriptionId). The description adds no additional meaning beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('set') and resource ('subscription') with 'price point' clarifying the target object. It clearly differentiates from sibling tools like set_iap_price (in-app purchases) and update_subscription (general updates). However, it doesn't mention the optional startDate behavior, leaving a small ambiguity in the precise action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is provided. The description does not mention alternatives or exclusions, such as when to use set_subscription_price versus update_subscription or set_iap_price. The intended context is only implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits, but it does not. It omits any information about side effects, required permissions, reversibility, or what happens on creation. For a mutating operation, this is a critical gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant or irrelevant words. It is appropriately concise for a simple create operation, following the principle that every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a complex environment of related subscription tools, the description is too sparse. It does not explain what happens after creation, how to verify success, or why one might choose this tool over siblings. The existing schema covers parameters, but the overall context is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover 100% of the parameters, so the baseline is 3 even though the tool description itself adds no parameter-specific meaning. The description does not duplicate or expand on the schema, but the schema is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('auto-renewable subscription'), clearly distinguishing it from sibling tools like 'create_subscription_group' and 'update_subscription'. It unambiguously conveys the tool's action and target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of prerequisites, such as needing a subscription group first, or any context for choosing between create, update, or list operations. This leaves the agent without explicit direction.
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?
With no annotations, the description carries the full burden of behavioral disclosure, but it only restates the action. It does not disclose side effects, potential validation errors, or what happens after creation. For a mutation tool, this lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise and to the point, though it could benefit from additional context without losing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four required parameters, no output schema, and no annotations, the description should explain expected outcomes or constraints. It does not mention return values, success behavior, or relationships to other resources, making it incomplete for an agent to fully understand the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for all four parameters (100% coverage), so the description adds no additional semantic meaning. Per the rubric, a baseline of 3 is appropriate when the schema already fully documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create' and the resource 'new in-app purchase', making the tool's purpose immediately obvious. It distinguishes itself from sibling tools like update_iap and delete_iap, which perform different actions on the same 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/5Does 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 does not mention any prerequisites, such as the need for an existing app or that subscription-based purchases should use create_subscription_group. It simply states what it does, leaving the agent to infer usage 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?
No annotations are provided, and the description carries the full burden of behavioral disclosure. It only implies a read operation via 'List', but does not mention response format, pagination, permissions, or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and resource. 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, but there is no output schema. The description does not mention that it returns a list or any details about the response structure, leaving some ambiguity for an agent. Given its low complexity, a slightly more explicit description would be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes 'appId' with 'The App Store Connect app ID' (100% coverage). The description's 'for an app' adds no new information beyond the schema, so it defaults to the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List subscription groups for an app' clearly states the action (List) and resource (subscription groups), with a scope ('for an app'). It differentiates from siblings like 'list_subscriptions' by naming a distinct resource, 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/5Does 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_subscriptions' or 'create_subscription_group'. It only states the function, without any context or exclusions.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool mutates state ('Create or update') but gives no details on idempotency, overwrite behavior, required permissions, or side effects beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no redundant information. It is front-loaded and to the point, though somewhat generic.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is minimal. The schema covers all parameters, but the description lacks any contextual guidance on prerequisites or behavioral expectations. However, the tool is relatively simple and the schema is rich, so it reaches the minimum viable threshold.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptive parameter descriptions, including the distinction between create (iapId) and update (localizationId). The tool description adds no additional parameter semantics beyond what the schema already provides, 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create or update') and clearly identifies the resource ('a localization for an in-app purchase'). It distinguishes this from listing or pricing tools, though it doesn't explicitly name sibling alternatives, so a 4 is appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 like list_iap_localizations or update_iap. It doesn't explain the create-vs-update decision based on localizationId, which is critical usage 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. The word 'List' suggests a read-only operation, but the description does not mention any specifics like whether results are paginated, what data is returned, or if any side effects occur. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential purpose without any redundant content. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, no annotations, and only one parameter, the description should clarify what the tool returns or any behavioral constraints. It does not, leaving the agent to guess at pagination, response shape, or other details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the only parameter (subscriptionId), so the schema already documents its meaning. The description adds 'for a subscription' which aligns with the parameter but does not provide additional semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List), the resource (promotional offers), and the context (for a subscription). This distinguishes it from generic list tools, though it does not explicitly differentiate from sibling tools like list_subscription_groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a subscription' implies this tool is used to fetch offers for a specific subscription, but there is no explicit guidance on when to use it over alternatives or any prerequisites. The usage context is implied rather than stated.
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?
There are no annotations, so the description must disclose behavioral traits. However, it only states the assignment action without any details on side effects, idempotency, permissions, or consequences for existing assignments. This is a mutation tool with no behavioral context beyond the verb 'Assign'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that directly states the tool's purpose with no wasted words. It is appropriately sized for a simple action with two parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema, no annotations), the description provides the core function but lacks important context such as prerequisites (e.g., build must exist, group must be in a certain state) or whether the assignment is cumulative. It is minimally viable but not rich enough for a mutation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described ('The build ID to add' and 'The beta group ID'). The description adds no new parameter meaning 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Assign') and the resources ('build' to 'TestFlight beta group'), making it distinct from sibling tools like list_beta_groups or get_build. It 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 Guidelines2/5Does 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 versus alternatives, nor any mention of prerequisites or typical scenarios. The description only states what it does, leaving the agent to infer usage context from the name and siblings.
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?
No annotations are supplied, and the description only states 'Create' without disclosing permission requirements, whether the page is immediately live, how to handle errors, or what the return value is. This is minimal behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant words. It conveys the essential purpose directly, though it lacks elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with two parameters, the description is adequate but not comprehensive. It lacks information about prerequisites, consequences (e.g., does it require localization?), or what the created page looks like. No output schema or annotations exist to supplement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters (name, appId) described in the schema. The tool description does not add additional parameter context, 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create), the resource (custom product page), and the scope (for an app). It distinguishes from sibling tools like update_custom_product_page and list_custom_product_pages by using the create verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not explain when to use this tool instead of create_iap or create_subscription_group, nor does it mention any prerequisites or alternative tools.
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 are absent, so the description must convey behavioral traits. It only says 'Get details', implying a read operation, but does not disclose error behavior, authentication needs, rate limits, or what data is returned. The lack of any annotation makes this a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, direct sentence with no redundant words. It is front-loaded with the verb and resource, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 no output schema. The description is adequate to understand the basic operation but is vague about what 'details' includes. Given the existence of get_experiment_results, clarifying that this returns experiment configuration rather than results would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a 100% description coverage with 'The experiment ID' for experimentId, so the baseline of 3 applies. The description adds no extra semantic context, such as the ID format or how to find it, but it doesn't need to compensate because the schema is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 'details for a specific A/B test experiment', clearly distinguishing it from siblings like list_experiments (which lists all experiments) and get_experiment_results (which fetches results). The scope 'specific' is explicit 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided beyond the purpose. The description does not mention when to prefer this over list_experiments or how to obtain the experimentId (e.g., from list_experiments). There is no explicit guidance on alternatives or exclusions.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the output includes conversion rates but does not explicitly confirm the operation is read-only, idempotent, or require specific permissions. Preconditions (e.g., experiment must exist or be completed) and error behavior are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action and includes the most valuable detail (conversion rates per treatment). There is no fluff, and every word contributes to understanding the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one well-documented parameter, the description is minimally viable but incomplete. It lacks details about the full return structure (beyond conversion rates), whether the experiment must be stopped/running, and any caveats about result interpretation. The absence of an output schema makes this gap more significant, but the tool's simplicity keeps it from being critically inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter (experimentId) with 100% coverage. The description does not add additional parameter-level context, but given the schema already provides the meaning, 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is specific and action-oriented: 'Get results for an A/B test experiment including conversion rates per treatment.' It clearly identifies the resource (experiment results) and key data returned, distinguishing it from tools like get_experiment which likely fetch configuration details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 get_experiment or list_experiments. The description does not mention exclusions, prerequisites, or scenarios where another tool would be more appropriate, leaving the agent to infer usage 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. The verb 'List' implicitly indicates a read-only operation, but the description does not disclose any additional behavioral traits such as pagination, ordering, or data scope beyond 'for an app'. This is thin for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It effectively uses the format 'List [resource] for [scope]', meeting the conciseness standard.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one well-documented parameter, the description is minimally adequate. However, there is no output schema and no mention of return format or potential limitations, leaving the agent without a complete picture. It is not as complete as the high-calibration get_calls example.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the single parameter appId clearly described. The description adds little beyond the schema, only clarifying that the app is the context. This 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'TestFlight beta groups' and scoping 'for an app'. This clearly distinguishes it from sibling tools like list_apps and list_beta_testers, 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/5Does 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 scenarios, exclusions, or relationships with sibling tools such as list_beta_testers or add_build_to_beta_group.
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 description discloses that the tool can create or update, but does not explain the conditional behavior (localizationId for updates vs subscriptionId for creates), nor any permissions, side effects, or idempotency. Since no annotations are provided, the description carries the full burden and falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no wasted words, front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal for a create/update mutation tool with no output schema and no annotations. However, the schema heavily documents parameters and the conditional mode, so the tool is usable. Still, the description lacks information about return values and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides descriptions for all 5 parameters (100% coverage), including the distinction between subscriptionId and localizationId. The description adds no additional parameter context beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('create or update') and resource ('localization for a subscription'), clearly distinguishing it from siblings like list_subscription_localizations and set_iap_localization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides no explicit guidance on when to use this tool vs alternatives, no prerequisites, and no exclusion criteria. The only hint is the implicit distinction from sibling tools, which is not stated.
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?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It omits any mention of permissions, side effects, idempotency, error cases, or return values. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with no filler. It front-loads the action and target, 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.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the schema covers all parameter meanings. However, with no output schema or annotations, the description does not mention what the response looks like or any behavioral caveats. This is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: each parameter has a description (pageId, name, visible). The tool description adds minimal value beyond the schema, but it does reiterate the relevant fields ('name or visibility'). This 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Update') and the resource ('custom product page'), and identifies the specific updatable fields ('name or visibility'). This distinguishes it from sibling tools like create_custom_product_page and get_custom_product_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no explicit guidance on when to use this tool versus alternatives like create_custom_product_page or get_custom_product_page. It simply restates the action, which duplicates purpose clarity. No prerequisites or exclusions are mentioned.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic action and does not mention whether this is a partial update, what fields get changed, whether any validation or approval is involved, or what the response format is. This is minimal for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded and wastes no words. However, it is so brief that it misses opportunities to add contextual value, so it is concise but not maximally effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, the schema fully documents parameters, and there is no output schema, so the description does not need to explain return values. However, the lack of annotations and absence of any usage or behavior details leaves notable gaps for an agent trying to decide whether and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with all three parameters (name, iapId, reviewNote) individually described. The tool description adds no additional meaning beyond the schema, which already provides the necessary parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 'in-app purchase', and the phrase 'existing' distinguishes it from create/delete/list siblings. This is unambiguous and immediately tells the agent 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (only for existing IAPs, not for creation), but it does not explicitly state when to use this tool over alternatives such as create_iap or set_iap_price. No exclusions or alternative references are given, so the 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Create' without mentioning side effects, required permissions, irreversibility, or what happens upon successful creation. This is minimal for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no superfluous words. It places the verb first and the object immediately after, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, and the schema fully documents all parameters. However, with no output schema or annotations, it does not explain the return value or post-creation state, leaving some ambiguity for a create operation in a complex API.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a clear description. The tool description adds no additional parameter meaning beyond what the schema already provides, meriting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('A/B test experiment') scoped to an app store version. It distinguishes from sibling experiment management tools like list_experiments, get_experiment, start_experiment, and stop_experiment by its creation focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied (this is the tool to create a new experiment) but there are no explicit when-to-use or when-not-to-use instructions, nor alternatives mentioned. It does not clarify interactions with siblings like start_experiment or create_custom_product_page.
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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the action 'Create' without mentioning side effects, permissions, uniqueness constraints (e.g., offerCode unique), or reversibility. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is appropriately concise and every word contributes to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema provides full parameter details, but the description lacks context such as prerequisites (e.g., subscription must exist), return value expectations, or error behavior. Since there is no output schema, some additional guidance would be beneficial, earning a middle score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with each parameter having a clear description. The tool description itself does not add further meaning beyond stating the resource, 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('promotional offer for a subscription'), clearly distinguishing it from sibling tools like create_subscription and create_subscription_group. It concisely conveys the tool's exact 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage from its clear action and resource, but provides no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. It is implied rather than stated.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'List all' without mentioning the response format, pagination, permissions required, or any other behavioral traits. This is insufficient for an API tool that may have side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, highly concise, and front-loaded with the action and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple (one parameter, no output schema). However, the description does not address key context such as the return value structure, pagination, or any use case distinctions. It provides the minimal essentials but leaves notable gaps for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, so the baseline is 3. The description adds minimal value beyond the schema—saying 'for an app' simply maps to appId but does not clarify the format or meaning beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('List') and resource ('custom product pages'), with an explicit scope ('for an app'). It distinguishes itself from sibling tools like get_custom_product_page, create_custom_product_page, and update_custom_product_page by clearly indicating a collection-level 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving all custom product pages, but it does not explicitly state when to use it versus alternatives like get_custom_product_page. There is no mention of when not to use it or any prerequisites, so the 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Get details,' which inherently implies a read-only operation, but it adds no context about permissions, error handling, or response format. The description does not go beyond what the tool name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource. It contains no filler words and efficiently conveys the essential 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter get operation, the description provides the essential elements: action, resource, and identifier. It does not specify what 'details' are included in the response, but given no output schema and the straightforward nature of a get, the description is largely sufficient. A slightly richer mention of return content would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 100% because the only parameter 'appId' has a description. The tool description rephrases the schema's 'App Store Connect app ID' as 'App Store Connect ID,' adding no new meaning. Since the schema fully documents the parameter, 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to get details for a specific app using its App Store Connect ID. The verb 'Get' is specific, the resource 'app' is named, and the identifier is identified. This distinguishes it from sibling tools like get_build, get_iap, or list_apps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the agent possesses an App Store Connect ID and needs details for one app. However, it does not explicitly mention when to avoid this tool or recommend list_apps for discovery. There is no direct comparison with alternatives, so guidance is implicit rather than explicit.
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?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states the action ('List') and content, with no mention of side effects, authentication, pagination, or error behavior. The read-only nature is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that avoids redundancy. Every element ('List', 'localizations', 'app store version', the parenthetical examples) contributes meaning, making it appropriately concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter list tool with no output schema, the description adequately conveys the resource and what the response will contain (descriptions, what's new, keywords per locale). It lacks edge-case details but is largely complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, as the schema already documents 'versionId' as 'The app store version ID'. The description adds extra context about the output content ('per locale') but does not enhance parameter meaning beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('localizations for an app store version'), and clarifies the content types with parenthetical examples (descriptions, what's new, keywords per locale). This clearly differentiates it from sibling tools like list_iap_localizations or update_keywords.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (for viewing localizations) but does not explicitly mention alternatives or exclusions. It lacks explicit guidance on when not to use it or how it relates to update_* tools or other list_localizations tools.
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?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only says 'List', implying a read operation, but doesn't mention whether it returns all localizations, pagination, sorting, or any access requirements. This is a significant gap for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no unnecessary words. It is front-loaded and easy to parse. However, it is slightly under-specified for a tool with no annotations, so it doesn't earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool, this is a minimum viable description: it states what the tool does and the target. But it lacks behavioral details, return value expectations, and any usage context beyond the obvious. It's adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes subscriptionId as 'The subscription ID' (100% coverage). The description adds minimal semantic value beyond restating that localizations are 'for a subscription', which is redundant. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List'), resource ('localizations'), and clarifies the target ('for a subscription'), while also describing what localizations are ('display names, descriptions'). This clearly distinguishes it from sibling tools like list_iap_localizations and set_subscription_localization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the context: use this when you need localizations for a specific subscription. However, it doesn't explicitly state when not to use it or mention alternatives, such as list_iap_localizations for in-app purchases or set_subscription_localization for updating.
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?
No annotations are provided, so the description carries the full burden. It indicates a write operation via 'set or update' but does not disclose side effects, reversibility, authorization requirements, or behavior on failure. Lacks behavioral detail beyond the mutation itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action, and contains no filler words. The mention of 'price point ID' is relevant and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter setter, the description provides the essential information: what action is performed and the key input. However, it lacks context about validation, whether the price is immediately effective, or how to discover price points (though the schema mentions the API). It is adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both iapId and pricePointId, so the schema carries the parameter meaning. The description reinforces the role of pricePointId but adds no new details beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('set or update'), the target resource ('in-app purchase'), and the specific aspect ('price'). It also specifies the mechanism ('using a price point ID'), distinguishing it from sibling tools like update_iap and set_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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for changing IAP pricing but provides no explicit guidance on when to use this tool versus alternatives such as update_iap or set_subscription_price. There is no mention of prerequisites like listing price points first (though that is in the schema) or exclusions.
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?
No annotations are provided, so the description must fully disclose behavioral traits. It only says 'stop' without addressing side effects, whether the action is reversible, prerequisites (e.g., must be in 'running' state), or impact on results—critical for an A/B testing 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/5Is 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 the meaning, making it optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a mutation operation, the description is too sparse. It omits important context such as what happens after stopping (e.g., can results be retrieved, is it irreversible), which is essential for a stop action in an A/B test workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents 'experimentId' with 100% coverage, so the baseline is 3. The description does not add any further meaning to the parameter, which is appropriate given the schema's clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Stop') and the resource ('a running A/B test experiment'), distinguishing it from siblings like 'start_experiment' and 'create_experiment'. The verb and object are 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'running' provides clear context that this tool is for experiments already in progress, and sibling names imply the lifecycle stage. However, it does not explicitly state when not to use it or mention alternatives.
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?
With no annotations, the description carries the burden of behavioral disclosure. 'Get' conveys a read-only operation, and the mention of 'rejection reasons if any' hints at conditional output. However, it does not describe return structure, error cases, or authentication needs, which would be valuable for a tool without an output 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, front-loaded sentence with no redundant words. It efficiently communicates the core purpose and a key feature (rejection reasons).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter get tool, the description is adequate but not complete. It mentions the return includes rejection reasons but does not describe other return fields or behavior when no submission exists. Without an output schema, more detail about the return shape would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so appId and platform are already well-documented. The description only says 'for an app' corresponding to appId, adding no extra context about parameter usage or constraints beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the latest review submission for an app and includes rejection reasons when present. This distinguishes it from sibling tools like get_review_status or submit_for_review by specifying 'latest submission' and 'rejection reasons.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'including rejection reasons if any' implies the tool is useful when rejection details are needed, but no explicit alternatives or when-not-to-use guidance is provided. The intended scenario is only mildly implied.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic action and fails to mention important details such as pagination, whether results can be filtered by platform (the schema includes this), or what data is returned per version. It neither confirms this is a read-only operation nor discloses any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that gets straight to the point without any filler or redundant information. It 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.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple listing operation with two well-documented parameters, but without an output schema or annotations, the description offers only the bare minimum. It does not describe the return format or any behavioral constraints, making it merely adequate rather than comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters with clear descriptions (appId and platform enum). The description adds minimal extra meaning beyond reinforcing that versions belong to a specific app, which is already obvious. Since schema coverage is 100%, 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (List) and clearly identifies the resource (App Store versions) and scope (for an app). This distinguishes it from sibling tools like list_apps and list_builds, 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for retrieving versions of a specific app, and sibling tool names reinforces the distinction. However, it does not explicitly state when to prefer this over alternatives or mention any exclusions or prerequisites.
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?
With no annotations, the description carries the full burden. The verb 'list' indicates a read-only operation, but the description does not disclose pagination, return type, or any other behavioral constraints. It adds minimal transparency beyond the purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately states the action and scope. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list operation, the description covers the core purpose and required input. However, it lacks any mention of response format, pagination, or error behavior, which would be useful since no output schema is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes groupId as 'The subscription group ID' with 100% coverage. The description's phrase 'within a subscription group' merely restates the parameter's role, adding no new semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('list') and resource ('subscriptions') with an explicit scope ('within a subscription group'), clearly distinguishing it from sibling tools like list_subscription_groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'within a subscription group' provides context that a groupId is required, but it does not explicitly mention alternatives or when not to use this tool. It implies usage rather than giving clear guidelines.
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?
With no annotations provided, the description carries the full burden of disclosing behavior. It merely states the action without mentioning side effects, prerequisites (e.g., an approved build), failure modes (e.g., already in review), or what happens after submission. This is a significant gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence of eight words. It communicates the core function with zero wasted language, fully front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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, the description is minimally adequate. However, it lacks context about return behavior, the optional nature of platform, and post-submission steps, leaving some ambiguity for an agent deciding whether and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with self-explanatory parameter descriptions for appId and platform. The tool description adds no additional parameter semantics beyond the schema, so 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (submit), the resource (an app version), and the target (App Store review). This distinguishes it from sibling tools like submit_iap_for_review and get_review_status, making its 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when submitting an app version for review. However, it does not explicitly mention alternatives or exclusions, such as using submit_iap_for_review for in-app purchases or get_review_status to check status, so it stops short of full guidance.
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?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only states that the action is independent of the app version, but does not disclose what submission entails, prerequisites, consequences, or reversibility. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a clear verb-object structure. Every word earns its place, and the qualifier 'independently of the app version' adds meaningful differentiation without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, no output schema, and no annotations, the description adequately communicates the tool's high-level purpose but omits behavioral details like what happens after submission and any state requirements. It is minimally viable but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single required parameter iapId is fully described in the schema ('The in-app purchase ID'). The description adds no parameter-specific meaning beyond what the schema already provides, 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Submit' and clearly identifies the resource 'in-app purchase' and the purpose 'for review'. The qualifier 'independently of the app version' effectively distinguishes this tool from the sibling submit_for_review, which likely handles app version submissions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'independently of the app version' provides clear context for when to use this tool—when submitting an IAP without a new app version. However, it does not explicitly name the alternative (submit_for_review) or state when not to use it, so it falls short of a fully explicit guideline.
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?
No annotations are provided, so the description must carry the behavioral transparency burden. It only says 'Update', which implies a mutation, but it does not disclose side effects, whether the update is a full replacement, reversibility, or any required permissions. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the action and resource, and no redundant words. It earns its place completely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 no annotations, the description is minimally sufficient. However, it lacks behavioral context such as what happens on success or whether the text is overwritten, which would be helpful for complete guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'localizationId' and 'whatsNew' having descriptive text. The description's mention of 'specific locale' adds a minimal contextual link to localizationId but does not go 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and clearly identifies the resource ('What's New text') and scope ('for a specific locale'). It distinguishes from sibling tools like update_app_description and update_keywords by language and 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: when you need to update the 'What's New' text for a particular locale. It provides clear context but does not explicitly mention when not to use it or list alternatives.
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?
No annotations are provided, so the description carries the full burden. The verb 'Get' clearly indicates a read-only operation, but it does not disclose authentication requirements, error behavior, or return format. Given the simplicity of a getter, this is minimally 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, short, well-structured sentence that states the action and resource directly. Every word earns its place, with no unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 one parameter, so the description is sufficient for basic invocation. However, there is no output schema and no mention of what 'details' means (e.g., fields returned), leaving some ambiguity for an agent expecting full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single parameter pageId with a clear description. The tool description adds no extra semantics beyond what the schema already provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with a clear resource ('custom product page') and scope ('specific'), distinguishing it from the sibling list_custom_product_pages. This unambiguously conveys it returns details for one page by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: use this when you need details for a specific page (as opposed to listing pages). However, it provides no explicit guidance about prerequisites (e.g., needing pageId from list_custom_product_pages) or exclusions compared to sibling 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?
No annotations are provided, so the description must convey behavior. 'Get' implies a read-only operation, but the description does not describe return format, error behavior, or what 'details' are included. It is minimally transparent but lacks richer 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence fully conveys the tool's core purpose with no redundant words. It is front-loaded with the verb and object, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool, the description is adequate: it names the action and resource. However, without an output schema, the return value is not explicit, and no alternative to list_iaps is noted, leaving minor gaps. Overall it is complete enough for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the only parameter 'iapId' is described in the schema as 'The in-app purchase ID'. The description adds no additional parameter semantics, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details for a specific in-app purchase' uses a specific verb ('get') and resource ('specific in-app purchase'), clearly distinguishing it from sibling tools like list_iaps (which lists all) and create_iap/update_iap/delete_iap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does 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 known in-app purchase ID), but it does not explicitly state when to use this tool versus list_iaps or other related tools. No alternatives or exclusions are 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?
No annotations are provided, so the description carries the full burden for behavioral disclosure. The verb 'Get' implies a read-only operation, but the description does not add details about permissions, error handling, or what happens if the version has not been submitted for review. It is minimally transparent but sufficient for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the verb 'Get' and the resource. Every word contributes to the meaning; there is no redundant or extraneous content. This is an exemplar of concise structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (single parameter, no output schema), the description provides the essential context: it retrieves the current review status for a version. It lacks detail on edge cases or the response format, but for a simple getter, the information is largely sufficient. A score of 4 reflects that it is nearly complete but could mention prerequisites or behavior when no review exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter versionId described as 'The app store version ID'. The tool description repeats this concept but adds no additional meaning beyond the schema. Since the schema fully documents the parameter, 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the current review status for an app store version' clearly specifies the operation (get) and the resource (review status for an app store version). It distinguishes itself from sibling tools like get_review_submission by focusing on the version's review status. This is a specific, unambiguous 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking review status but provides no explicit guidance on when to use this tool versus alternatives like get_review_submission or submit_for_review. There is no mention of exclusions or preferred contexts, so usage is only inferred.
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?
With no annotations provided, the description carries the full burden. 'List all' clearly communicates a read-only operation, but the description adds no extra behavioral context like pagination, ordering, or response format. It is adequate but minimal, not disclosing any potential side effects or constraints beyond the version scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is 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 the meaning, making it exceptionally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one required parameter and no output schema, the description provides sufficient information to select and invoke the tool. It defines the scope (app store version) and the action (list all). Minor gaps include lack of explicit description of the return value or any conditional behavior, but these are not critical 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the versionId parameter, describing it as 'The app store version ID'. The description's 'for an app store version' mirrors the schema without adding new meaning. Baseline of 3 is appropriate since the schema handles the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List) and the resource (A/B test experiments), scoped to an app store version. It distinguishes itself from siblings like get_experiment by indicating it lists all experiments rather than retrieving a single one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for an app store version' provides context on when to use the tool, but the description does not explicitly mention alternatives or exclusions, such as using get_experiment for a single experiment. The usage is implied rather than explicitly guided.
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?
With no annotations provided, the description carries the full burden. It indicates a read operation ('List') and clarifies what localizations include, but does not disclose details like whether all locales are returned, pagination behavior, or required permissions. It adds some context beyond the name but lacks richer behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the verb front-loaded. Every word adds value: it identifies the action, the resource, and clarifies the domain-specific term 'localizations'. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (1 required parameter, no output schema), the description covers the essential purpose. It explains what localizations are and ties to IAP context. It doesn't explain the response format, but that is implied by 'list' and the description of localizations. Sibling set_iap_localization provides context that this is the read operation. Slightly more detail about return structure could earn a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the sole parameter iapId as 'The in-app purchase ID' (100% coverage). The description adds no additional meaning about the parameter, only repeats 'in-app purchase' in the text. Baseline of 3 is appropriate since 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List) and resource (localizations for an in-app purchase), with parenthetical clarification of what localizations are (display names, descriptions). It distinguishes from sibling tools like list_iaps (which lists IAPs) and set_iap_localization (which modifies). The verb+resource 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need to view localizations for a specific IAP, but it does not explicitly say when to use this tool versus alternatives. It doesn't mention that this is the read counterpart to set_iap_localization or that subscription localizations would use a different tool. No explicit exclusionary 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?
With no annotations, the description carries the burden. It clearly indicates a read-only listing operation, but provides no detail on return format, pagination, or any side effects. It is transparent about its main behavior, but lacks extra 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single, concise sentence with no redundancy. It is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one parameter and no output schema, the description adequately conveys the purpose. It doesn't detail the return structure, but 'List' implies a list of IAPs. The simplicity of the tool does not require more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: appId is described as 'The App Store Connect app ID'. The description adds 'for an app' but does not enrich the parameter meaning beyond what the schema already provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all in-app purchases for an app' uses a specific verb ('List'), resource ('in-app purchases'), and scope ('for an app'). It clearly distinguishes from sibling tools like get_iap (singular) and create_iap/update_iap/delete_iap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use when you need all IAPs for an app, versus get_iap for a specific one. However, it does not explicitly state when to use it over alternatives or mention any exclusions. The context is clear but not fully 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?
With no annotations provided, the description carries the burden of behavioral disclosure. It implies a read-only operation but does not disclose additional traits such as pagination, permissions, or whether the list is exhaustive. The mention of optional territory filtering adds a behavioral nuance, but overall the description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the core purpose and the optional filter in a concise manner. No words are wasted, and the information is immediately accessible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with only two parameters and no output schema, the description provides sufficient context: it lists price points and shows that territory is an optional filter. It could be more complete by specifying the return format or any default behavior, but given the low complexity, it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already fully explains both parameters. The description adds the phrase 'optionally filtered by territory', which is already captured by the optional property in the schema. Thus, the description adds little beyond what is already structured.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 'available price points for a subscription', with an optional filter by territory. This distinguishes it from sibling tools like list_subscriptions or list_subscription_offers, 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for when to use the tool (when listing price points for a subscription), but it does not explicitly mention alternatives or when not to use it. There is no reference to sibling tools or exclusions, so the 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Update,' implying mutation, but gives no details about permissions, side effects, validation requirements, or reversibility. This lacks the transparency needed for an agent to understand the operational impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no extraneous words. It front-loads the core information and is easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with two plain string parameters and no output schema, the description covers the essential purpose and scope. It does not mention prerequisites (e.g., the localization must already exist) or reference related tools, but it is adequate for the tool's straightforward nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with descriptions for both parameters ('New app description' and 'The app store version localization ID'), so the baseline is 3. The tool description's 'specific locale' reinforces the role of localizationId, but adds no additional semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (Update), the resource (app description), and the scope (for a specific locale), distinguishing it from sibling tools like update_whats_new and update_keywords. The verb+resource+scope structure is precise 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a specific locale' provides clear context on when to use this tool—when updating a localized description. It does not explicitly exclude alternatives or mention related tools, but the scope is sufficiently clear for basic 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates this is a read-only listing operation, but it does not mention potential behaviors such as pagination, ordering, or any limits on the result set. For a simple tool this is acceptable, but more context could be added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundant information. Every word earns its place, and the structure is front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the extreme simplicity of the tool (no parameters, no output schema), the description covers the core functionality adequately. It states what the tool does and its scope. A note about the return format could be beneficial, but it is not essential for such a straightforward list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is trivially complete. The description adds the scope qualifier 'all apps', which clarifies the parameterless nature. With 0 params, a baseline of 4 is appropriate, and the description does not need to compensate for any missing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all apps in your App Store Connect account' uses a specific verb (list) and resource (apps), and clearly identifies the scope (all apps in the account). This distinguishes it from sibling tools like get_app (single app) and list_app_versions (versions of an app). The purpose is unambiguous and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need an overview of all apps, but it does not explicitly state when to use this tool versus alternatives like get_app or list_app_versions. There are no exclusions or alternative tool mentions, so the guidance is only 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?
No annotations are provided, so the description itself must convey behavioral traits. 'List' implies a read-only operation, but beyond that there is no disclosure of pagination, return format, or limitations. This is minimally sufficient for a simple read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary purpose and the optional filter. Every word is useful, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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, the description gives enough information to understand what it does and how to use it. It doesn't detail return shape or pagination, but that's acceptable given the tool's simplicity and the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single parameter 'betaGroupId' with a clear description. The tool description merely restates 'optionally filtered by beta group', adding no new semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and identifies the resource 'TestFlight beta testers', with an optional filter by beta group. This clearly distinguishes it from sibling tools like list_beta_groups or list_apps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool to list testers, optionally filtered by a specific beta group. It doesn't explicitly name alternatives or exclusions, but the resource scope is obvious enough for an agent to select appropriately.
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?
No annotations are provided, so the description carries the transparency burden. It states the read-only nature ('List') and filter options, but does not disclose pagination, ordering, default limits, or error behavior. For a simple list operation, this 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, 10 words, front-loaded with the action and resource. Every word is useful and 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with three parameters, and the description covers its core purpose. It doesn't mention return format or pagination, but for a list operation with no output schema this is not a severe gap. The description is complete enough for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters. The description adds the word 'optionally' to clarify that filters are optional, but this is already implied by the schema's required list. Minimal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'builds for an app', and mentions optional filters. This distinguishes it from sibling tools like get_build (single build) and list_app_versions (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this to list builds for an app, with optional filters. It doesn't explicitly name alternatives or when-not-to-use, but the purpose is unambiguous given the tool name and description.
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?
With no annotations provided, the description carries the burden of disclosing behavioral traits. It adds the prerequisite that the IAP must be a draft and not submitted for review, which is valuable. However, it does not disclose other potentially important behaviors such as whether deletion is permanent or what happens if the IAP already has localizations or other related data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and resource, then adds the key condition. There is no wasted wording or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema) and the description provides the core usage context: what it deletes and the prerequisite. It does not explicitly state success/failure behavior, but that is largely implied for a deletion operation. Given the low complexity, the description is adequately complete, though a note on irreversibility would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the single parameter 'iapId' as 'The in-app purchase ID', giving 100% schema description coverage. The tool description adds no additional semantic information about the parameter, so it does not improve upon the schema. 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'draft in-app purchase', and adds a critical constraint ('only works if not yet submitted for review') that distinguishes it from sibling tools like update_iap or submit_iap_for_review. This 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit condition for when the tool is applicable ('only works if not yet submitted for review'), which effectively tells the agent when to use it and when not to. This serves as a clear usage guideline even though it does not name alternative tools.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/yuraist/appstoreconnect-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server