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

No annotations are provided, so the description carries full burden. It implies a read operation but does not disclose permissions, error handling, or side effects. The description is sparse on behavioral details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is single-sentence, front-loaded with purpose and key details. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool with no output schema, the description provides adequate info on what is returned. However, it lacks details on error cases or output format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (app_id has description and pattern). The tool description does not add additional parameter context beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it gets detailed app info including versions, build status, and release state. It distinguishes from sibling tools like list_apps (which lists apps without details).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions using list_apps to find the app_id, providing a prerequisite. However, it does not explicitly state when not to use or suggest alternatives.

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

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

With no annotations, the description carries the full burden. It accurately describes the output (a playbook), notes that manual steps are flagged inline, and even mentions 'Free' to convey cost behavior. While it does not explicitly state side effects, the tool's nature as a read-only guide makes this sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, front-loaded with 'START HERE' to immediately convey priority. 'Free' is a short, useful addition. Every word earns its place with no repetition or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple one-parameter schema and lack of output schema, the description adequately covers what the tool returns, when to use it, and even cost. It does not enumerate the topic list (handled by the schema), so it is complete for its simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the schema already details the 'topic' parameter ('Which playbook. Omit for the overview + topic list.'). The tool description adds general usage context ('Call with topic') but no additional semantic meaning beyond what the schema provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'START HERE' and a clear verb+resource: 'Returns the exact end-to-end playbook for an App Store task.' It also distinguishes itself from sibling tools by flagging that it covers manual ASC-website/Xcode steps that no API can do, making it a guide/orientation tool rather than a direct action tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly instructs to 'Call with topic to orient before any multi-step flow,' providing clear when-to-use context. However, it does not explicitly name alternative tools or exclusion cases, relying on 'START HERE' to imply its role as the initial entry point.

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

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

With no annotations, the description carries the burden. It discloses what is checked (credentials, connection, tier) and that it returns fixes. It implies a read-only, diagnostic behavior, though it doesn't explicitly state it won't modify anything or how sensitive data is handled.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core purpose. Every sentence adds value: the specific checks, the promise of exact fixes, and the trigger condition. No fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter diagnostic tool with no output schema, the description fully covers what it does, what it returns, and when to run it. It is complete and self-sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and the schema is empty, so the baseline for parameter semantics is 4. The description does not need to add parameter-specific details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verbs ('diagnose', 'checks') and names concrete resources (.p8 key, Key ID, Issuer ID, live connection, license tier). It clearly distinguishes itself from sibling tools by focusing on setup validation and returning fixes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs 'Run this first if something isn't working,' providing clear when-to-use context. However, it does not mention when not to use or name alternative tools, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden. It discloses key behaviors: no credit card required, immediate activation, session-persistent effect, and the need to ask for a real email. It also explains what unlocks as a result, making the side effects clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the primary action, followed by precise usage instructions and a key behavioral note. Every sentence adds value, with no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 2-param tool with no output schema, the description covers purpose, usage, and key behavior. It does not describe the exact response format or edge cases (e.g., already used trial), but given the tool's straightforward nature and that it directs the agent to proceed, it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description reinforces the 'email' parameter by instructing to ask for an email, but does not add new semantic detail beyond the schema's existing descriptions for 'tool' and 'email'. It earns the baseline but no more.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Start a free 7-day Pro trial', with a specific resource scope ('all 41 tools including the full write/control plane') and distinguishes it from sibling tools that manage apps or reviews. It is a specific verb+resource combination.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use it: 'Call this whenever a Pro tool is refused and the user wants to proceed'. It also provides pre-conditions and instructions ('ask them for an email address first') and notes that it activates in the current session so the previously blocked tool can be retried.

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

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

With no annotations provided, the description discloses important behavioral traits: it defaults to the newest processed build, requires confirm:true, and warns that Apple notifies every tester immediately with an irrevocable notification. It also notes the Pro feature requirement. This goes beyond just stating the action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three short, focused sentences: purpose, required confirmation with consequence, and licensing note. Every sentence provides essential information without any fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutating tool with no output schema, the description covers key aspects: purpose, default behavior, required parameter value, irreversible side effect, and feature restriction. It could mention what happens on failure or whether existing assignments are replaced, but overall it is quite complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema descriptions cover 100% of parameters, the description adds meaning by clarifying that confirm must be set to true ('Needs confirm:true'), which is not clearly indicated in the schema's required fields. It also reinforces the build_id default behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Assign a build to a TestFlight beta group so testers can install it'. It also mentions the default behavior (newest processed build), which distinguishes it from related operations like attaching a build elsewhere or inviting individual testers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool (to make a build available to a beta group) and a critical prerequisite (confirm:true). It doesn't explicitly mention alternatives or exclusions, but the context is sufficiently clear, and the 'Pro feature' note adds a usage restriction.

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

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

With no annotations, the description must disclose the write behavior, but it only mentions the default selection ('newest processed build') and the 'Pro feature' restriction. It does not state that attaching a build replaces any existing build association, whether it can be undone, or what permissions are required. As a mutating operation, this lack of side-effect disclosure is a notable gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded and direct, with no redundant wording. The 'Pro feature' note is a necessary restriction, and the sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is a mutation with no output schema, so the description should explain what happens after attachment or when it is appropriate. It only provides the default selection behavior and the Pro restriction, but omits important context such as whether the version must be in a specific state, what a successful attach means for the release process, and how to verify the action. Given the low complexity, a slightly fuller description would make it complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides 100% coverage with descriptions for both app_id and build_id. The description adds little beyond the schema, except confirming that omitting build_id defaults to the newest processed build, which aligns with the schema's 'newest VALID build' note. Therefore, it meets the baseline of 3 for parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Attach a build') and the target ('the editable version'), with a specific default behavior ('newest processed build'). It distinguishes from sibling tools like assign_build_to_group by specifying the editable version rather than a beta group. The 'Pro feature' note adds a scope constraint, but does not obscure the core purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is used to associate a build with the editable release version, but does not explicitly state when to use it over alternatives like assign_build_to_group or create_version. It lacks explicit exclusions or prerequisites, such as the version being in a particular state or the build being valid. The only hint is the default to the newest processed build, which is more of a selection rule than usage guidance.

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

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

With no annotations, the description carries the transparency burden. It discloses implementation (xcodebuild), environment requirement (Xcode), and input requirements (scheme, plist), but omits important behavioral traits such as whether the output directory is overwritten, code signing prerequisites, time-to-completion, or what exactly is produced besides the .ipa.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the main action, and every sentence adds value. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose and key prerequisites, but for a build tool with 6 parameters and no output schema, it could elaborate on expected outputs, failure scenarios, or how to handle workspaces. It is minimally adequate but not rich.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema fully documents all parameters. The description mentions scheme and ExportOptions.plist as required but adds no extra meaning beyond what the schema already provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Build, archive, and export a signed .ipa via xcodebuild'. It uses a specific verb-resource pair and is distinct from all sibling tools, which focus on App Store Connect management.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context and prerequisites: 'requires Xcode on this Mac', 'Needs a scheme and an ExportOptions.plist', and 'Pro feature'. It does not explicitly mention alternatives or when-not-to-use, but the tool's unique function makes this less critical.

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

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

With no annotations, the description carries the full burden. 'Look up' clearly implies a read-only operation, and the listed fields indicate no side effects. However, it doesn't disclose behaviors like rate limits, error handling for not-found apps, or what the return format looks like, and the 'Pro feature' is vague about enforcement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the action and data fields. Every word earns its place, including the 'Pro feature' note. No fluff or redundant detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 2-param lookup without output schema, the description covers the main purpose and return fields. It doesn't mention default country or pagination/limits, but these are either in the schema or minor for the tool's simplicity. Overall sufficient for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already documents both parameters (query as app name/ID, country as two-letter code) with 100% coverage. The description's 'Search by name or App Store ID' repeats the schema's query description, adding no new semantic value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action ('Look up any app on the App Store') and lists the data provided (ratings, reviews, version, price, category, release notes). It distinguishes from siblings like app_details by emphasizing 'any app,' implying competitor or third-party lookup.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: it's for looking up any app, which implies use for competitor research. It mentions search methods (name or App Store ID), but doesn't explicitly state when not to use it or name alternatives like app_details. The 'Pro feature' hint adds some context about access.

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

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 mentions idempotency, which is a useful trait, but omits critical details such as required permissions, side effects (e.g., does it submit for review?), reversibility, and expected response. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, tightly worded sentence conveys the core purpose and key constraints with zero waste. It is front-loaded with the action 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is complex (10 parameters, 7 required, no output schema, no annotations), yet the description is minimal. It does not explain return values, prerequisites, approval flow, or behavior on duplicate calls beyond 'idempotently'. The description is insufficient for an agent to confidently invoke the tool without further information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by clarifying that 'price_usd' is the USA store price and 'one-time purchase' reinforces the meaning of the type enum. This adds value without redundant repetition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Create'), a precise resource ('in-app purchase'), and scoping details (idempotent, non-consumable or consumable, USA price). It clearly distinguishes from sibling tools like create_subscription, making the tool's purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance is given for when to use this tool over alternatives such as create_subscription or set_iap_review_screenshot. The only contextual hint is 'Pro feature', which is too vague to guide usage decisions.

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

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

With no annotations, the description carries the full burden. It discloses idempotent creation, automatic territory availability, and Pro feature status, which are valuable behavioral traits. However, it omits side effects on existing subscriptions and what the response contains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the primary action and key modifiers. Every word contributes value, with no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with 14 parameters and no output schema, the description covers key behavioral context but omits return values and any required setup beyond 'Pro feature'. Sibling context helps, but the description could be more complete for such a complex tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all 14 parameters are already documented. The description adds context about USA price and optional trial but doesn't provide meaningful semantics beyond the schema field descriptions. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates an auto-renewable subscription within a group, with specific price, trial, and territory behaviors. It distinguishes itself from siblings like create_iap by emphasizing subscription-in-group scope and idempotency.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description offers no guidance on when to use this tool versus alternatives (e.g., create_iap) or any prerequisites apart from 'Pro feature'. There is no mention of prohibited scenarios or complementary tools.

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

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

With no annotations provided, the description carries the full burden. It discloses the irreversible nature (cannot be undone), the requirement for confirm:true, and that it is a Pro feature. This goes beyond the schema by explaining why confirmation is required.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences: purpose, requirement and reason, and Pro feature. No wasted words, front-loaded with the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations or output schema, the description covers purpose, usage timing, irreversibility, and licensing. It doesn't mention return values or error cases, but the schema fully documents parameters, making it reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the confirm parameter's irreversibility rationale, but it does not add detail for the other parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool creates a new editable App Store version to prepare the next release. It distinguishes from sibling tools like release_version and update_version_metadata by emphasizing 'new' and 'editable', 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage before launching a next release by saying 'prepare your next release,' but does not explicitly state when to use this tool versus alternatives, nor when not to use it.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It clearly indicates the tool is read-only (a briefing) and lists the data categories included. It also notes 'Pro feature,' which signals access restrictions. However, it does not explicitly state that no modifications occur, nor does it discuss data freshness, rate limits, or behavior if no apps exist. This is adequate but has gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no filler. The first sentence lists the content categories, and the second sentence adds value by highlighting the 'one call' benefit and the 'Pro feature' caveat. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one optional parameter, the description provides the core purpose, the scope ('across all apps'), and the key content areas. It does not explain return format or prerequisites beyond 'Pro feature,' but the absence of an output schema and low complexity make this acceptable. A 4 reflects it is nearly complete, with minor room for added detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema describes the only parameter 'days' with its meaning and default ('Look back N days for reviews (default 3)'), giving 100% coverage. The description adds no additional information about the parameter, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function with specific verb+resource: it provides a morning briefing aggregating version status, recent reviews, rejections, and action items across all apps. This distinguishes it from sibling tools like review_status or list_reviews, which focus on individual areas. The phrase 'One call for full situational awareness' further reinforces its unique cross-app aggregation purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for when to use the tool: when wanting a single, comprehensive overview of app health ('One call for full situational awareness'). It implies a preference over making multiple calls, but does not explicitly name alternatives or exclusions. This is more than no guidance but less than explicit when-not/alternatives, warranting a 4.

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

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

With no annotations provided, the description fully compensates by disclosing key behaviors: uses Sampling and Elicitation, drafts in the review's locale, never auto-posts, returns a draft, and is a Pro feature. It omits potential error conditions but covers the essential 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is highly concise with four short sentences, each adding distinct value: core function, locale/tone nuance, explicit non-posting behavior, and pro feature flag. Every sentence is purposeful and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters and no output schema, the description explains the tool's purpose and workflow but lacks details about the draft's format or content. It also does not specify behavior when Elicitation is unsupported, leaving some gaps in completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds some context beyond the schema, such as that the draft is in the review's locale and that tone may be asked interactively. However, it does not significantly enhance parameter understanding for the remaining parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool drafts a public reply to a single App Store review, using MCP Sampling. It uniquely distinguishes itself from sibling tools like list_reviews and triage_reviews by focusing on drafting responses, not listing or triaging.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states it never auto-posts and always returns a draft that the user must post manually, providing clear context on when to use this tool. However, it does not explicitly contrast with alternatives like review_status or other sibling tools.

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

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 warns that the action is irreversible ('cannot be recalled') and that it triggers a real email, which is significant context beyond the bare 'invite' verb. It doesn't mention return behavior, but the key side effects are disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no fluff. The first sentence states the core purpose, and the second adds a necessary caveat. Every word earns its place, and the most important warning is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 5 parameters with full schema coverage and no output schema. The description covers the main action, a critical side effect, and a Pro feature restriction. It doesn't explain what happens after the invite, but for a simple action with good schema support, this is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already covers all 5 parameters with descriptions (100% coverage), so baseline is 3. The description adds extra meaning for 'confirm' by explaining that it must be set to true and that it sends a real, non-recallable email. This goes beyond the schema's 'Required. Sends a real email...' by emphasizing the irreversibility.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with a specific verb and resource: 'Invite an external tester by email and add them to a beta group.' This clearly identifies the action and distinguishes it from sibling tools like list_beta_groups or assign_build_to_group. It also adds a 'Pro feature' tag, which provides useful scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for when to use the tool, including the critical requirement 'Needs confirm:true' and the consequence that Apple emails a real person. However, it does not explicitly mention alternatives or exclusion criteria, which keeps it just below a 5.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It discloses an external dependency (Uses iTunes Search API), output elements (difficulty, competing apps, budget usage), and access level (Pro feature). However, it does not explicitly state that the operation is read-only or describe error/rate-limit behavior, which would be useful given the absence of annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: three sentences, each adding value. It starts with the primary purpose, then describes key outputs, and ends with external API and access constraints. No fluff or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple keyword analysis tool with full schema coverage, the description is sufficiently complete. It covers the main purpose, key behaviors, and access constraints. Minor gaps like the exact meaning of 'budget usage' or expected return format are not critical given no output schema and the tool's straightforward nature.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with both parameters (app_id and extra_keywords) documented. The tool description does not add parameter-specific meaning beyond the schema, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function with a specific verb ('Analyze'), resource ('your app's keywords'), and purpose ('against search competition'). It distinguishes from siblings by focusing on keyword analysis, mentioning difficulty, competing apps, and budget usage, which sets it apart from tools like competitor_snapshot or metadata_diff.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when keyword competition analysis is needed, but it does not explicitly state when to use or when not to use this tool versus alternatives. The mention of 'Pro feature' hints at access constraints, but no exclusions or alternative tool comparisons are provided.

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

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

With no annotations, the description should disclose behavioral details. It claims to list 'all apps' but the input schema reveals a limit parameter (default 50, max 200), which means it may not return all apps if there are more than 200. The description does not mention this limitation or any pagination behavior, making it somewhat misleading for a tool that says 'all'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, directly front-loaded with the action and resource, and includes only essential information (what is returned). No wasted words or redundant content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple listing tool with one optional parameter and no output schema, the description covers the core purpose and return fields. However, it fails to mention the 'all' vs. limit caveat, which is a notable gap in completeness for a tool that might be used to enumerate every app.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema fully documents the single 'limit' parameter with its description, range, and default. The tool description adds no extra parameter details, so the baseline of 3 applies since schema coverage is 100%.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'List' with a clear resource ('apps in your App Store Connect account') and enumerates the returned fields (name, bundle ID, SKU, App ID). This clearly distinguishes it from sibling tools like app_details, which likely targets a single app.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description clearly conveys that this is for getting an overview of all apps, which implicitly tells the agent when to use it (e.g., before drilling into app_details). It does not explicitly name alternatives or exclusions, but the context is clear enough for a listing tool.

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

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 does disclose that it is a 'Pro feature,' indicating an access/entitlement requirement, but it does not elaborate on return format, potential errors, or other behavioral details. For a simple list operation, this is minimal but present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences that immediately convey the core purpose and a notable restriction. There is no wasted wording, and it is effectively front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a low-complexity tool with one parameter, no output schema, and no nested objects. The description covers the purpose and a key restriction ('Pro feature'), and the schema supplies the app_id requirement. It is adequately complete, though it could mention expected output or read-only nature.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description fully covers the single parameter app_id (100% coverage), so the description adds no additional parameter semantics. Baseline 3 is appropriate given the schema's completeness.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the action (list) and the resource (TestFlight beta groups for an app). It is specific and distinguishes from sibling tools like assign_build_to_group or invite_beta_tester, which handle different operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It simply states that it lists beta groups, with no mention of prerequisites, alternatives, or exclusions. The 'Pro feature' note is a requirement, not a usage guideline.

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

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

With no annotations provided, the description carries the full burden for behavioral disclosure. It adds useful context about the processing state and what VALID means, and notes it is a Pro feature. However, it does not disclose other behaviors such as whether the operation is read-only, any rate limits, or what fields are returned for each build.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that conveys the core functionality and an important clarification about VALID state. It avoids repetition and unnecessary detail, earning full marks for efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a simple 2-parameter tool with no output schema, and the description provides a basic understanding of what it does. However, it does not explain the response structure or additional details like pagination or ordering, which might be expected given the absence of an output schema. It is adequate but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already explains 'limit' and 'app_id' clearly. The description adds no new parameter information beyond what the schema states, 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'List recent builds for an app with processing state (VALID = ready to use).' It uses a specific verb+resource and clarifies the meaning of VALID. However, it does not explicitly differentiate this from sibling tools like review_status or app_details, though the resource 'builds' is distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. It only states the function and mentions 'Pro feature' as a limitation, but does not explain context, exclusions, or how this compares to other build-related tools such as wait_for_build or attach_build.

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

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

With no annotations, the description must convey all behavioral traits. It mentions 'Pro feature' hinting at access restrictions, but lacks details on rate limits, pagination behavior (despite limit parameter), or authorization needs. The behavior beyond filtering is opaque.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with three clear phrases: the main action, a key filter, and a usage constraint (pro feature). Every sentence earns its place without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 parameters, no output schema, and no annotations, the description adequately states the core purpose and a filter, but it omits context about pagination, sorting options, and whether the tool is read-only. It is minimally complete for a simple list tool but lacks depth.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds 'Filter by rating' but that is already explicit in the rating parameter schema. No additional value is provided for other parameters like sort or limit, which are fully documented in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (list), the resource (customer reviews), and additional context (filter by rating, pro feature). It distinguishes the tool from siblings like review_status or triage_reviews which have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for listing reviews with optional rating filter, but it does not explicitly state when to use this tool versus alternatives like review_status or triage_reviews. No exclusions or alternative guidance is provided.

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

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. While it notes 'Pro feature' and explains that 'complete' releases to 100%, it does not mention that all actions alter the live rollout state, that 'complete' is irreversible (though noted in the schema's confirm parameter), or any other risks or prerequisites. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, information-dense sentence that front-loads the purpose, enumerates the actions, and includes a relevant note about the Pro requirement. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description gives the core purpose and actions, and the schema covers all parameter details. However, it lacks behavioral warnings (e.g., irreversible completion, live impact) and usage guidelines. For a simple control tool with no output schema and no annotations, the description is adequate but not comprehensive enough to fully prepare the agent for safe invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds value by elaborating on the 'action' parameter: listing the valid actions and clarifying what 'complete' does ('release to 100%'). This goes beyond the schema's sparse 'Phased release action' description, though it does not add information about 'app_id' or 'confirm'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Control') and resource ('7-day phased rollout'), enumerating the exact actions (start, pause, resume, complete) and clarifying that 'complete' means releasing to 100%. This clearly distinguishes it from sibling release tools like 'release_version' which likely handles full releases.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: this tool is for managing a 7-day phased rollout. It implies when to use it (whenever controlling a phased rollout is needed) but does not explicitly mention when not to use it or suggest alternative tools. Since the context is clear but no exclusions are stated, it earns a 4.

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

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

With no annotations, the description carries the full burden. It mentions 'Pro feature' and the scope of comparison (fields and locales), but does not explicitly note that the tool is read-only, whether a pending version must already exist, or how errors are handled. This is adequate but not detailed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the primary purpose ('Compare metadata') followed by specifics on what changes are shown. There is no filler or repetition of schema details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one parameter and no output schema, the description gives a solid understanding of its purpose and what the output will contain (changes in descriptions, keywords, and release notes across locales). It could be more explicit about prerequisites (like an existing pending version) or the exact output format, but overall it is reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for the single parameter app_id, which is already described as 'App Store Connect app ID'. The description adds no additional meaning to the parameter, 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function with a specific verb ('Compare') and resource ('metadata between your live and pending app versions'), and further specifies what fields are compared (descriptions, keywords, release notes) across locales. This distinguishes it from sibling tools like update_version_metadata (which writes) and release_notes (which simply shows notes).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is used to review changes before updating metadata, which provides clear context. However, it does not explicitly state when to use it versus alternatives or exclude other tools. The 'Pro feature' note adds access context but no 'when-not-to-use' guidance.

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

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

With no annotations, the description carries the burden of disclosing behavior. It states the tool 'Extract[s]' (implying read-only), 'Categorizes changes', and 'provides writing guidelines', which is useful. However, it does not disclose prerequisites like git installation, error behavior, or whether a Pro subscription is required for execution, leaving some ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is exceptionally concise, consisting of three short sentences that each add distinct value: purpose, behavior, and a key constraint. There is no fluff or redundancy, and the most important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (3 optional parameters, no output schema), the description provides a sufficient overview: it explains the input (git commits since tag) and output (structured data with categories and writing guidelines). It doesn't detail the exact output structure, but for a tool like this, that level of detail is likely not essential.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema—it mentions 'since last tag' in the purpose but does not elaborate on defaults or value formats that the schema doesn't already cover.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function with a specific verb ('Extract') and resource ('git commits since last tag'), and directly connects it to writing App Store release notes. It distinguishes itself from sibling tools by focusing on generating structured data for release notes, which is unique among the provided tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when you need to generate release notes from git history, but it does not provide explicit when-to-use/when-not-to-use guidance or mention alternatives. The 'Pro feature' note is a constraint but not usage guidance.

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

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 tool 'checks' and 'catches rejection causes,' which implies a read-only audit. However, it doesn't explicitly confirm that no modifications are made, nor does it describe the output format or any potential side effects (e.g., requiring a build to exist). This leaves some behavioral ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences, front-loaded with the primary purpose ('Pre-submission audit'), followed by specific checks and the benefit. Every phrase carries meaning, including the 'Pro feature' note, which is a useful business context. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one parameter and no output schema, the description covers the what (checks metadata, screenshots, etc.), the when (pre-submission), and the why (catch rejection causes). It lacks an explicit statement of what the tool returns (e.g., a report of issues), but the overall context is sufficient for an agent to use it appropriately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, app_id, is fully described in the schema as 'App Store Connect app ID,' providing 100% coverage. The description does not add details about the parameter beyond implying it identifies the app to audit, but since the schema already explains it, the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool's function as a pre-submission audit, listing specific checks (metadata, character limits, screenshots, build status) and its goal (catching rejection causes). This distinguishes it from siblings like submit_for_review (which submits) and review_status (which shows current 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'before you submit' provides clear temporal context for when to use this tool, implying it should be called prior to submit_for_review. While it doesn't explicitly name alternatives, the 'pre-submission' framing and the list of checks imply it's the gatekeeper before submission, giving adequate guidance.

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

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 adds valuable context beyond the schema by noting the action is 'Outward-facing' (public impact), requires 'confirm:true' as a safety guard, and is a 'Pro feature' (entitlement). This gives the agent a clear picture of the tool's behavior, though it could mention irreversibility or specific failure modes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence (17 words) that front-loads the primary purpose ('Release an approved version... to the public App Store') and then adds key qualifiers ('Outward-facing', 'requires confirm:true', 'Pro feature'). Every phrase earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple action tool with 2 parameters and no output schema, the description is reasonably complete. It covers the prerequisite state, the public nature, the confirmation requirement, and the entitlement. It does not describe return values, but the tool's simplicity and the schema's parameter descriptions make this an acceptable omission.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides descriptions for both parameters (app_id and confirm), giving 100% coverage. The description adds no additional parameter-level semantics beyond restating that confirm:true is required, which is already in 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Release an approved version ... to the public App Store.' It includes the specific state (PENDING_DEVELOPER_RELEASE) and outward-facing nature, which distinguishes it from related tools like submit_for_review or release_preflight, 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool: it is for releasing a version that is already in the PENDING_DEVELOPER_RELEASE state. It also notes that confirm:true is required, which serves as a usage condition. However, it does not explicitly state when not to use it or name alternative tools.

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

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

No annotations are provided, so the description carries the burden. It discloses the possible status values, which is useful, but does not explicitly state that this is a read-only operation, whether it requires any special permissions, or what the return format looks like. For a simple status check, 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the action and resource, and lists the possible statuses. There is no wasted wording; it's optimally concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one parameter, no output schema, and no annotations, the description covers the core purpose and expected outcomes. It could be more specific about the return format or error cases, but the status list is sufficient for a simple read-only check.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 100% of the parameter description ('App Store Connect app ID'), so the baseline is 3. The tool description adds no additional meaning beyond the schema, but since the schema is complete, this is acceptable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Check' and clearly defines the resource: 'current App Store review status'. It enumerates the possible outcomes ('in review, waiting, approved, or rejected'), making the tool's purpose unmistakable and distinguishing it from siblings like 'submit_for_review' or 'list_reviews'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is for checking the review status of an app, which is a distinct action among the sibling tools. It doesn't explicitly state when to use it instead of alternatives, but the context is clear enough for a simple status check. No exclusions are needed.

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

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

With no annotations, the description carries the full burden, but it only says 'Download' and lists content. It does not disclose output format, authentication requirements, rate limits, or any side effects. The 'Pro feature' note is a minor access constraint but insufficient for behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three short sentences, front-loaded with the action and key content. No unnecessary words or repetition; it is concise and scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description lacks usage context, return format, and behavioral caveats. With no output schema and no annotations, it should include more operational guidance (e.g., what the downloaded file looks like, when to use it, any prerequisites) to be complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning to the parameters beyond what the schema already provides—it only mentions report content unrelated to parameter syntax or semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Download sales/downloads summary', identifying both a specific verb and resource. It lists the report contents (units, proceeds, territory), which distinguishes it from sibling tools focused on app management, reviews, or metadata.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Description gives no guidance on when to use this tool versus alternatives like daily_briefing or other reporting tools. 'Pro feature' is a licensing note, not a usage context. Schema provides vendor_number help, but the description lacks explicit when/when-not guidance.

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

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

The description discloses that Apple computes the final age rating from the provided declarations, which is a behavioral trait beyond the schema. It also mentions 'Pro feature', hinting at access restrictions. However, it doesn't explain side effects, reversibility, or permissions, and since no annotations are present, the description carries the transparency burden but only partially fulfills it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long and includes a practical example. Every word earns its place, with no repetition of schema details. It is efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the moderate complexity (nested object param) and no output schema, the description provides sufficient context: purpose, example, Apple's rating calculation, and pro restriction. It doesn't mention return values but that's covered by the schema. The description is complete for a simple set operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes both parameters with 100% coverage, so the description adds limited value. It provides an example of the declarations map but doesn't introduce new meaning beyond the schema's explanation of keys and value types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Set the app's age-rating content declarations'. This uses a specific verb+resource and distinguishes from sibling set_* tools by focusing on age rating. The added context about Apple computing 4+/9+/12+/17+ reinforces the tool's specific domain.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (pass declarations map) and notes it's a 'Pro feature', but does not explicitly state when to use this tool vs alternatives or provide exclusions. No comparison with sibling tools like set_privacy_nutrition or set_app_metadata is given.

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

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 discloses the requirement for an explicit choice and warns that passing [] takes the app off sale worldwide. It also indicates a 'Pro feature' restriction, but does not mention whether changes are immediate, irreversible, or how they interact with existing territories beyond what the schema already states.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences long and front-loaded with the purpose, followed by the critical usage constraint. Every sentence adds value without repetition or filler, achieving excellent conciseness while covering the most important behavioral nuance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no output schema and moderate complexity, the description adequately covers the essential context: the core action, the required explicit choice, the off-sale case, and the Pro feature requirement. The schema handles parameter-level details, so the description does not need to repeat them. Minor gaps remain, such as the default behavior of available_in_new_territories, but that is documented in the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides 100% coverage, but the description adds meaningful semantics by clarifying the mutual exclusivity between territories and all_territories, and the special case of [] for taking the app off sale. This goes beyond the individual parameter descriptions, which could be misinterpreted without the explicit-choice context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb and resource: 'Set the app's country/region availability.' This unambiguously distinguishes it from sibling tools like set_app_price or set_app_metadata, which handle other aspects of app configuration.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context on how to use the tool by requiring an explicit choice among a territories list, all_territories:true, or an empty list for taking the app off sale. It also notes the tool is a 'Pro feature.' However, it does not explicitly mention when to use it relative to alternatives, though no similar availability tool exists among siblings.

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

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

With no annotations, the description adds useful behavioral context: 'Each applied only if provided' explains partial updates, and 'Pro feature' alerts the agent to plan constraints. However, it does not mention permissions, side effects, or reversibility, which are still relevant 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded, stating the purpose in the first sentence, then the update semantics and Pro feature in two short sentences. There is no fluff or repetition of schema details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (6 parameters, no output schema), the description covers the purpose, update semantics, and access constraint. Minor gaps remain around prerequisites, exact response behavior, or interaction with other metadata tools, but it is reasonably complete for a setter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by clarifying that each field is applied only if provided (non-destructive), giving a concrete example for category IDs ('HEALTH_AND_FITNESS'), and explicitly tying encryption to export compliance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Set' and the resource 'submission-required app basics', enumerating exactly which fields are affected (category, copyright, content rights, export compliance). This distinguishes it from sibling tools like update_version_metadata or set_age_rating by focusing on app-level metadata.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'submission-required' provides clear context: this tool is for setting app metadata needed for App Store submission. However, it does not explicitly name alternatives or give when-not-to-use guidance, so it stops short of a full 5.

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

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

There are no annotations, so the description carries full burden. It discloses the behavior of creating a price schedule with 'USA base, auto-equalized', but does not state whether it overwrites an existing schedule, idempotency, or any permissions needed. Some useful context is given, but important side-effect details are missing 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the action and object. Every word adds value: method, requirement, and feature flag. No wasted text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (2 params, no output schema), and the description covers purpose, mechanism, requirement, and pro limitation. The only noticeable gap is the lack of explicit statement about overwriting existing price schedules, but overall it is complete for its complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description's note 'price_usd: 0 for free' repeats the schema, but 'USA base' adds minor context beyond the schema's 'USA price tier'. It does not add substantial new meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Set' and the resource 'app's base price', and adds the mechanism 'by creating its price schedule (USA base, auto-equalized)'. This is specific and distinguishes it from any sibling tool despite no direct pricing sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states 'Required before submission', giving a clear when-to-use context. It also flags it as a 'Pro feature', implying an audience restriction. However, it does not mention any alternatives or exclusions, but no alternatives exist among siblings, so this is strong.

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

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 honestly states the tool is not API-addressable, returns steps and a deep link, and is a Pro feature. This goes beyond the schema by explaining what the tool actually does (guidance) and its non-mutating nature, though it does not mention authentication or potential 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences that front-load the primary purpose and immediately provide key behavioral qualifiers. Every phrase earns its place, with no filler or redundant repetition of the tool name or schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one parameter, no output schema, and a simple guidance function, the description adequately covers the essential information: what it does, how it behaves (non-addressable, returns steps), and a prerequisite (Pro feature). It could benefit from a brief note on when one would need EU DSA trader status, but overall it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema fully describes the only parameter (app_id) with 100% coverage, so the description need not add parameter details. The description adds no additional semantic value for the parameter, which is acceptable given the schema coverage, but it does not enhance understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Declare' with the resource 'EU Digital Services Act trader status', which clearly identifies the tool's purpose. It also distinguishes this tool from siblings by its unique subject matter and explicitly notes it is not API-addressable, clarifying its role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context by stating 'Not API-addressable; returns the exact steps + deep link' and 'Pro feature', which suggests it is for guidance rather than direct action. However, it does not explicitly state when to use this tool versus alternatives, nor does it name any sister tool as an alternative.

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

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 the outcome (leaving MISSING_METADATA), the mechanism (resolves product by product_id automatically), and a requirement (Pro feature). It does not detail whether the screenshot replaces an existing one or mention permissions, but it gives a meaningful account of the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences. The first sentence states the purpose and condition; the second adds the automatic resolution and 'Pro feature'. There is no redundancy or filler, and the key information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-parameter upload tool with no output schema, the description covers the essential context: what it does, when it is needed, and a key behavioral detail (automatic product resolution). It does not explain return values or error handling, but the operation is simple enough that these omissions are non-critical.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining that product_id is used to resolve the product automatically, which clarifies the role of that parameter beyond its schema description. This extra semantic context justifies a score above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action: 'Upload the App Review screenshot a subscription or in-app purchase needs to leave MISSING_METADATA.' It names the specific resource (subscription or IAP review screenshot) and the outcome (leaving MISSING_METADATA). This distinguishes it from sibling tools like upload_screenshots by targeting IAP-specific screenshots and emphasizing automatic product resolution.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool: when a subscription or in-app purchase is in MISSING_METADATA state and needs a review screenshot. It does not explicitly name alternatives or state when not to use, but the 'subscription or in-app purchase' scope and the automatic product_id resolution provide clear context for selecting this tool over generic upload screenshots.

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

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

With no annotations provided, the description transparently discloses the key behavior: it does not actually set the label via API but returns instructions and a deep link. It also notes the 'Pro feature' limitation. This goes well beyond the typical description, though it could mention permissions or error handling to be fully complete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, using only 3-4 short sentences. It is front-loaded with the purpose, followed by the key caveat and parameter guidance. Every sentence carries meaningful information, and there is no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 parameters, no output schema, no annotations), the description is quite complete. It explains what it does, the limitation that Apple doesn't expose an API, the return type (steps + deep link), and a special parameter case. It could mention what happens when data_not_collected is false, but overall it provides sufficient context for an AI agent to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, providing baseline semantics for both parameters. The description adds meaning by explaining the 'data_not_collected:true' path and implying that app_id is used to generate the deep link. This enriches the schema definitions, earning a score above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Configure the App Privacy nutrition label,' which is a specific verb+resource that clearly distinguishes this tool from other 'set_' sibling tools. It unambiguously states the tool's function without ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: it's for configuring privacy labels, and the caveat 'Apple does not expose this via API; returns the exact steps + deep link' tells the user what to expect. It also gives a specific usage example ('Pass data_not_collected:true for the 'Data Not Collected' path'). However, it does not explicitly contrast with alternatives or state when not to use it, though no sibling tool seems to handle this function.

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

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

No annotations are provided, so the description carries the burden. It mentions 'on the editable version' and 'Required before submission,' but does not disclose side effects such as overwriting existing contacts or how demo_account_required interacts with omission. This is a moderate 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that states the action, the resource, and a key constraint with no wasted words. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter tool with no annotations and no output schema, the description covers the core purpose and a critical workflow requirement. The schema handles parameter details, but the description could have added more behavioral context, such as what happens if demo_account_required is omitted.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The tool description adds no additional parameter-level semantics beyond what the schema already provides, not even highlighting the demo account fields as optional.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Set') and identifies a clear resource ('App Review contact and optional demo account') on the editable version. This distinguishes it from sibling tools like submit_for_review or release_notes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states 'Required before submission,' providing a clear when-to-use context. It does not mention alternatives or exclusions, but the statement gives sufficient guidance for when this tool should be invoked.

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

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

With no annotations, the description carries the full burden. It discloses the main operations: downloading profiles, installing them, and writing a plist, plus the prerequisite. Could mention side effects like overwriting existing profiles, but overall it is transparent enough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: the first states the purpose and key actions, the second notes a prerequisite and feature level. Every sentence contributes value; no fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with two parameters and no output schema, the description covers what, why, and prerequisites. It lacks detail on return values or exact effects of installing profiles, but given the moderate complexity, it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for both parameters (app_id and output_plist). The description adds context about the app's profiles but does not introduce additional parameter semantics, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to prepare App Store binary signing by downloading/installing provisioning profiles and writing an ExportOptions.plist. This distinguishes it from siblings like build_and_archive or upload_binary, which focus on building and uploading.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly explains when to use the tool: when lacking cloud-signing permission. It also states a prerequisite (Apple Distribution certificate in keychain). It does not name alternatives or when-not-to-use, but the context is sufficiently clear.

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

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

With no annotations provided, the description fully discloses side effects: it is outward-facing, requires confirm:true, submits IAPs first, and aborts on first IAP to avoid orphaning. It also mentions returning manual steps, giving a complete picture of behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded with the main action. Each of the four sentences adds value: purpose, order of operations, abort condition, and confirm/pro feature. The use of all-caps for critical conditions is purposeful and not wasteful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a submission tool with no output schema, the description covers the essential flow, including the abort branch and manual steps. It sufficiently explains the tool's role and caveats, and success return details are handled by sibling tools like review_status.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already explains all three parameters. The description adds emphasis on confirm being required but does not offer significant new parameter-level meaning, 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool submits the editable version to Apple App Review, with a specific verb and resource. It also distinguishes itself from siblings like release_version by focusing on the submission step and mentions the sequence with IAPs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides clear context that this tool is for submitting to App Review and notes the confirm requirement and Pro feature. However, it does not explicitly name alternatives or when not to use it, so it falls short of a 5.

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

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

With no annotations provided, the description carries the full burden. It discloses the sampling mechanism and that it's a read-only operation ('Pull ... reviews'), which is sufficient for an analytical tool. It also notes 'Pro feature,' indicating a potential constraint. However, it could mention scope limits or data retention briefly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise at three sentences, front-loading the primary function. The second sentence about sampling cost is relevant context. A minor improvement would be integrating the 'Pro feature' note more naturally, but overall not verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (sampling, 4 parameters, no output schema), the description covers the main action, output structure, and a key constraint (Pro feature). It could mention the data source recency or how action buckets are determined, but it is largely complete for an analytical tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with each parameter described. The description adds no additional parameter-level insights beyond what the schema already provides (e.g., app_id pattern, limit hard cap). Baseline score of 3 is appropriate as the schema is self-sufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Pull recent App Store reviews and use MCP Sampling to cluster them'), the resource (App Store reviews), and the output (themes with counts, quotes, action buckets). It distinguishes itself from sibling tools like list_reviews by adding clustering functionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for theme analysis of reviews but does not explicitly state when to use this tool versus alternatives (e.g., list_reviews for raw data). It mentions the sampling cost benefit but lacks exclusion criteria or prerequisite context.

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

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

With no annotations provided, the description carries the transparency burden. It discloses two useful behavioral traits: validation against Apple character limits before writing, and that it modifies the editable version, alerting the agent to potential scope restrictions. However, it does not mention overwrite behavior, auth requirements, failure modes, or reversibility, leaving important operational unknowns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the action and resource, followed by a useful behavioral note and a Pro feature flag. Every sentence earns its place without redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with 11 parameters and no output schema, the description gives a solid overview and a key validation detail. However, it omits whether partial updates are supported, what the return value is, and prerequisites beyond 'editable version'. These gaps are notable but not fatal, making it adequate yet incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already describes each parameter in detail. The description adds only a high-level grouping of fields, which is somewhat redundant with the schema. It does not add syntax, format, or update semantics 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb ('Edit') and resource ('App Store metadata on the editable version'), and enumerates the exact fields (description, keywords, what's-new, promotional text, URLs, app name, subtitle). This distinguishes it from sibling tools like set_app_metadata or release_notes by specifying it targets the version-level metadata.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: it edits the editable version's metadata and validates character limits before writing, implying it's for pre-submission updates. However, it does not explicitly mention when not to use it or name alternatives (e.g., set_app_metadata for app-level fields), so it falls short of full exclusionary guidance.

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

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

No annotations are provided, so the description carries the burden of disclosing behavior. It states the upload is a write operation requiring 'confirm:true' and mentions the 'Pro feature' gating, which is useful. However, it doesn't disclose what happens with 'confirm:false,' the return format, or any side effects (e.g., does it replace an existing build?). Still, the presence of explicit confirmation is a meaningful 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact: one sentence plus two short contextual flags. It is front-loaded with the core action and includes high-value notes (confirm requirement, Pro feature) without rambling. Slight deduction for not using structured formatting (e.g., bullets) but it's efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given this is a write/intructive tool with no annotations and no output schema, the description covers the essentials: what is uploaded, how, and the confirmation requirement. However, it omits details like whether the tool waits for Apple's processing, returns a tracking ID, or what errors to expect if the API key is invalid. For a Pro-feature upload tool, more detail would be helpful, but it is minimally viable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters. The description adds minimal extra meaning beyond the schema, except that 'confirm' is mandatory for the upload to actually happen, which is also partially in the schema ('Must be true to actually upload'). The description does not clarify things like absolute path format or platform defaults beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific action: 'Upload a signed .ipa to App Store Connect via altool, using your API key.' This distinguishes it from siblings like 'upload_screenshots' and 'attach_build,' though it doesn't explicitly name an alternative tool. It identifies the resource (.ipa), the destination (App Store Connect), and the mechanism (altool/API key).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear context on when to use it (uploading a signed .ipa to App Store Connect) and the mechanism (via altool with API key). It also notes the confirmation requirement ('requires confirm:true') and that it is a Pro feature. While it doesn't explicitly contrast with sibling tools like 'upload_screenshots' or 'attach_build,' the resource specificity makes the use case clear.

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

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

With no annotations provided, the description must convey behavioral context. It does disclose the reserve/upload/commit flow, indicating a stateful write operation, but it omits important details such as prerequisites (e.g., an existing version/localization), potential side effects (committing is likely irreversible), or rate limits. The description is not transparent enough for a mutation tool without 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences (plus a short 'Pro feature' tag) with the main verb and resource front-loaded. No wasted words; it conveys purpose, scope, and a key behavioral trait without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has moderate complexity (4 params, no output schema) and no annotations. The description explains the core purpose and flow but does not mention return values, preconditions (e.g., which display types are valid, whether a version must already exist), or how many screenshots are required per display type. While the schema fills in parameter details, the operational context is incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% — each parameter already has a clear description (e.g., 'Absolute paths to PNG/JPEG screenshot files, in order'). The tool description adds no additional parameter-level meaning beyond the schema. Baseline 3 applies when the schema does the heavy lifting, which is the case here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb+resource: 'Upload screenshots to a version localization for a device display type' with an example. It clearly distinguishes this from sibling tools like upload_binary or set_iap_review_screenshot by focusing on screenshots and the localization/display-type target.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool (uploading screenshots for a specific display type in a version localization) and notes 'Handles Apple's reserve/upload/commit flow', which signals a multi-step process. However, it does not explicitly mention when not to use it or name alternatives, so it stops short of a 5.

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

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

The description discloses key behavioral traits: it blocks for up to 30 minutes by default, and it is a 'Pro feature.' This risk of holding the session is prominent. However, it doesn't specify what happens on timeout (error vs. return) or whether partial results are returned, leaving a minor gap given there are no annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, each adding value: purpose, usage caveat with alternative, and a licensing note. The most important information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a polling tool with fully described parameters, the description covers the core behavior (blocking, duration, fallback). It lacks an explicit note about the return value or timeout behavior, but given no output schema and the simple nature of the tool, the description is sufficiently complete for an agent to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the description need not repeat parameter details. The mention of '30 minutes by default' aligns with max_wait_seconds, but adds no new syntax or constraints beyond the schema. Baseline 3 is appropriate when the schema fully documents parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool polls until the newest uploaded build reaches VALID status, making the ship flow a single call. The verb 'poll' plus the target resource 'newest uploaded build' and the goal 'VALID' leaves no ambiguity about what the tool accomplishes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly advises when not to use the tool ('if you should not hold the session that long') and directs the user to the alternative 'call list_builds yourself instead.' This is a clear when-to-use and when-not-to-use guideline, plus a named alternative.

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