storebridge-mcp

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds the 5-result limit and asserts both stores are supported, but omits return format, error behavior, or edge cases. This is adequate but not rich beyond annotations.

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

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

The description is two short sentences, front-loaded with the core capability and result limit. The second sentence adds useful scope information without unnecessary 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?

The tool is simple and well-covered by annotations and schema, but the description does not explain return structure, locale handling, or fallback behavior. It is sufficient for basic invocation but not fully 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 all four parameters. The description does not add parameter-specific meaning beyond the schema, so the baseline score of 3 applies.

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

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

The description clearly states the tool returns up to 5 autocomplete completions for a partial search query, using a specific verb (returns) and resource (autocomplete completions). This distinguishes it from sibling tools like search_apps or get_aso_keywords.

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 'for a partial search query' implies the primary use case, but the description does not explicitly compare with sibling tools or state when not to use it. No exclusions or alternate tool references 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no extra behavioral traits such as rate limits, required authentication, or response size. It primarily lists output contents and id format, which are more about purpose and parameters than behavior, so it doesn't go beyond the annotations.

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

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

The description is two sentences and efficiently packs the tool's purpose and key parameter semantics. The first sentence gives a comprehensive but focused list of output fields, and the second clarifies the id format with examples. No redundant or filler 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?

With no output schema, the description compensates by enumerating the major response fields (rating histogram, version history, IAP flag, etc.). Combined with solid annotations and clear parameter descriptions, it gives the agent a strong understanding of what to expect. Minor omissions like error behavior or missing fields for certain stores are not critical given the annotations and the tool's 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 covers 100% of parameters with descriptions, including the id format (Apple trackId or Google package name). The description repeats the id explanation but adds concrete examples (6448311069, com.whatsapp) that clarify the expected format. No other parameters gain new meaning beyond what the schema already 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 opens with 'Full details for one app' and provides an extensive list of returned data fields (description, version, release dates, rating, etc.). It clearly identifies the tool's specific function (fetching comprehensive app details) and distinguishes it from siblings like get_app_datasafety and get_app_reviews by being the general-purpose detail fetcher.

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 makes the tool's use case clear: retrieving complete app metadata for a single app. However, it does not explicitly mention alternative tools for narrower queries (e.g., get_app_reviews for reviews) or provide when-not-to-use guidance. The context is clear but lacks explicit exclusions or referral to 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?

Annotations indicate read-only, idempotent, non-destructive operations. The description adds behavioral context beyond these by specifying that non-Google store values yield a not_supported error and enumerating the returned data categories, which is not in the annotations.

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

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

The description is two sentences that efficiently convey the tool's purpose, output contents, and a key error condition. No wasted words; front-loaded with the main purpose.

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 no output schema, the description compensates by listing the content areas returned (data shared, collected, security practices, privacy policy URL). It also covers the platform limitation with an error example. The tool is simple (3 params), so this is sufficiently complete, though it lacks explicit return structure details.

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 all three parameters (100% coverage). The description does not add new parameter-specific semantics beyond the schema; it merely reinforces the store='google' constraint already in the schema. 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 identifies the tool as retrieving the Google Play Data safety section for a single app, listing the specific content areas (data shared, collected, security practices, privacy policy URL). It distinguishes itself from sibling tools like get_app_permissions by focusing on data safety, and the Google-only limitation is explicit.

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 the tool is Google-only and that passing store='apple' results in a not_supported error, providing a clear exclusion. It gives context that it is for the data safety section of one app, implying when it should be used, though it does not directly compare to 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?

The annotations already establish that this is a safe, read-only, idempotent operation. The description adds useful context beyond the schema: the grouping by permission group and the specific error behavior when an invalid store value is provided. This goes beyond what annotations provide.

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

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

The description is two sentences, front-loaded with the main purpose and immediately followed by the critical constraint. Every word earns its place, with no fluff or redundancy. It is exceptionally concise and well-structured.

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 read-only tool with fully documented parameters and clear annotations, the description provides all necessary context: the exact data returned, the grouping structure, and the error behavior for a common mistake. No important information appears missing for correct tool 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?

The input schema already provides complete descriptions for all three parameters (id, lang, store) with 100% coverage. The description reiterates the Google-only restriction, matching the schema, but adds no additional semantic detail beyond what is already in the structured parameter descriptions.

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 and resource: retrieving Google Play declared device/data permissions for one app, grouped by permission group. It distinguishes itself from sibling tools like get_app and get_app_datasafety by focusing on permissions and the Google-only 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 explicitly says 'Google only' and warns that passing store="apple" returns a not_supported error, which is a clear when-not condition. However, it doesn't name alternative tools or explain when to prefer this over get_app_datasafety, so it lacks full explicit guidance on 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?

The description discloses important behavioral traits beyond the annotations: Apple's hard cap of 500 reviews, page limits (1-10), error on page>10, unsupported sort 'rating', and Google's token-based pagination with effectively unbounded results. These details are not present in the annotations and significantly enhance the agent's understanding 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 compact, consisting of two sentences that front-load the core purpose and then efficiently detail platform-specific constraints. Every sentence provides useful information without redundancy, making it well-structured and easy to scan.

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

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

For a tool with 8 parameters and two platform variants, the description covers the key operational quirks and pagination details, which are the main sources of complexity. However, since there is no output schema, the description does not explain the return value structure (e.g., review fields), which slightly reduces completeness. Overall, it is nearly complete for the tool's purpose.

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 covers 100% of the parameters with detailed descriptions, so the baseline is 3. The description adds some context (e.g., the aggregate cap of 500 per country, the RSS feed source), but most of the parameter-specific details are already in the schema. Thus, the description doesn't add substantial meaning 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 opens with 'Reviews for one app,' which clearly identifies the tool's function: retrieving reviews for a single app. It distinguishes itself from sibling tools like get_app or get_app_permissions by focusing specifically on reviews, and the platform-specific details reinforce its unique 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 provides clear context on when to use the tool (for one app's reviews) and how to handle pagination differences between Apple and Google. It gives explicit usage tips like 'page>10 returns an error' and 'pass the nextToken from a prior call's pagination to page forward.' However, it doesn't explicitly name alternatives or state when not to use this tool, 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?

Beyond the annotations (read-only, idempotent), the description adds meaningful behavioral details: Apple's ~200 id round-trip limit, Google's fan-out/coalescing, the response shape difference ('apps' array vs 'app' object), and the store='both' constraint. This significantly enriches the agent's understanding.

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 core action, and every clause conveys useful information without redundancy. It is efficient and well-structured.

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 the essential operational context: how to invoke single vs batch, the response shapes, and the store='both' restriction. With the schema providing parameter details and annotations covering safety, the description is complete for this tool's 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?

The schema already describes all five parameters (100% coverage), so the baseline is 3. The description adds value by explaining the relationship between bundleId and ids, clarifying that store='both' is only supported for batch lookups, and providing a concrete bundleId example, which goes 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 states a specific verb ('Resolve'/'fetch') and resource ('apps'), and clearly distinguishes the batch capability from the single lookup by bundleId. It explicitly mentions the dual mode (single vs batch) and the store='both' option, differentiating it from sibling tools like get_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 provides clear context for when to use batch lookups (when fetching many apps at once) versus a single bundleId lookup, and notes the Apple/Google fan-out behavior. However, it does not explicitly name alternative tools or state when not to use this tool, so it stops short of the highest bar.

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 results are derived from live search/suggest results (not panel data) and that every result is labeled estimated:true. This adds significant value beyond the readOnly and openWorld annotations, which do not specify data source or estimation status.

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 efficiently conveys the tool's purpose, output fields, and data source. Every clause 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?

With no output schema, the description enumerates the result fields and the estimation flag, providing a clear picture of the return value. It does not cover pagination or limitations, but those may not be critical for this tool's use case.

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 parameters are already documented in the schema. The description only refers to 'seed term' as the input, adding marginal value 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 the tool provides directional keyword ideas for a seed term, with specific metrics (difficulty score/label, traffic score, result count, top competitors). It distinguishes from siblings by noting it derives from live search/suggest results, not panel data, which sets it apart from other ASO 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 have a seed term and need ASO keyword ideas. It provides clear context but does not explicitly mention alternatives or when not to use the tool, which is a minor gap given the sibling tools available.

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?

Beyond the read-only and idempotent annotations, the description discloses that each search is live, fan-out is capped at 20, results are labeled estimated:true, and this is a snapshot rather than historical tracking. These details add meaningful behavioral context not present in the annotations.

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

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

Three short sentences deliver the essential information without redundancy. The description is front-loaded with the main purpose and each sentence adds value: scope, live-search behavior, and the estimated/snapshot nature.

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 no output schema, the description covers key behavioral caveats: live search, fan-out cap, estimated flag, and point-in-time semantics. Combined with the rich annotations and complete parameter schema, this gives an agent sufficient context to invoke the tool 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 input schema already provides full descriptions for all five parameters, including max 20 keywords and defaults for country/lang. The description adds the live-search and fan-out behavior but does not significantly enhance parameter-level semantics beyond what the schema offers.

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 returns point-in-time ASO keyword rank for one app across up to 20 keywords, using a specific verb and scope. It distinguishes itself from sibling tools like get_aso_keywords by emphasizing this is a rank snapshot, not tracking or keyword discovery.

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: use for a current rank snapshot with up to 20 keywords, with a live search per keyword and fan-out cap. It explicitly says this is not rank tracking over time, offering a when-not-to-use cue, though it does not name an alternative tool for tracking.

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?

Annotations already indicate a safe, read-only, idempotent operation. The description adds valuable behavioral context by explaining the differing data sources between Apple and Google, which is not present in the annotations. It does not describe the return format in detail, but the added store-specific behavior is useful beyond the structured metadata.

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: one sentence with a clear action prefix ('List categories for a store') followed by a brief, relevant explanation of store-specific behavior. Every word earns its place; 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 tool with only two parameters, strong annotations, and no output schema, the description provides sufficient context. It explains the key behavioral difference between Apple and Google, which is the main complexity. A slight gap is the lack of return-type details, but given the tool's simplicity and the annotations' coverage, this is not a major 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?

Schema description coverage is 100%, providing basic meaning for both parameters (lang, store). The description adds extra semantic value by explaining how the 'store' parameter alters behavior—Apple returns its static genre map, Google returns its categories() constants. This goes beyond the schema's simple 'Target store' description, justifying a score above the baseline of 3.

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 categories for a store.' This is a specific verb+resource combination. It also distinguishes the tool from siblings by noting the Apple/Google genre-map difference, making it unique among app-focused siblings like get_app_reviews or search_apps.

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 implicitly conveys when to use the tool: when you need categories for a store, with the store parameter determining the source. It provides clear context for both supported stores (Apple returns a static genre map, Google returns categories() constants), but does not explicitly mention alternatives or when not to use it. This is acceptable for a simple 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?

The annotations already declare readOnlyHint and idempotentHint, and the description adds useful behavioral context: the potential empty array with meta.stale=true for Google when a region is broken, and the return format 'App summary plus rank'. This goes beyond what annotations alone provide.

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 (three sentences) and front-loaded with the core purpose. It is mostly efficient, though the phrase 'Google list()' is slightly confusing since the tool is named get_charts, and could distract the agent.

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 provides store-specific nuances and a caveat, but with no output schema it remains vague about the exact structure of returned entries. Saying 'App summary plus rank' is a decent high-level indication, but not fully complete for an agent to anticipate the response shape.

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 restates parameter meanings (type, category) but adds no new details beyond the schema. The only extra nugget is 'omit for the overall chart', which is already present 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 tool's purpose: returning ranked top-chart entries (App summary plus rank) for a store. This is a specific and concrete description that distinguishes it from sibling tools that focus on individual app details, ASO rank, or categories.

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 does not provide any guidance on when to use this tool versus alternatives. It explains parameter semantics (type, category) but never mentions sibling tools like get_aso_rank or get_categories, nor does it state explicitly that this is the tool for store-wide charts.

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 annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the description adds minimal behavioral context. It mentions the id format for each store, which is helpful but not deep behavioral disclosure. No contradictions with annotations.

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

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

The description is extremely concise—two sentences that convey the core function and the id format. No filler or redundancy; every 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?

For a relatively simple read-only tool, the description adequately states what is returned and clarifies the id format. With no output schema, the description does not elaborate on the structure of the returned data, but the purpose is clear enough. The schema covers all parameters, so the description 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 input schema has 100% coverage with descriptions for all parameters. The description's note about `{id}` being Apple artistId or Google developerId repeats the schema's parameter description, adding no new semantic information. Baseline 3 applies due to full schema coverage.

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 returns 'a developer record plus their published apps', which is a specific and distinct purpose. The name 'Get developer portfolio' and the description differentiate it from sibling tools like get_app (single app) or search_apps.

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 retrieving developer details and associated apps, but does not explicitly compare it to alternatives or state when not to use it. No exclusions or alternative tool references are provided, so the guidance is only implied.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint true, and destructiveHint false, so the safety profile is clear. The description adds that the tool is 'first-class' on both stores, which is useful context about cross-store behavior, but does not disclose other behavioral traits such as potential empty results or rate limits.

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 front-loads the core purpose ('Customers also bought' / related apps) and adds the key detail about store support. Every word contributes value, with no unnecessary 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?

The tool is a simple read-only retrieval operation with five parameters, two of which are required, and no output schema. The description covers the purpose and key context (cross-store support), and the schema covers parameter details. It is adequately complete for an API of this complexity, though it could mention output format or pagination behavior, but that is not critical given the simple 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%, so the input schema fully documents all five parameters including meanings for id, store, lang, limit, and country. The description does not add parameter semantics beyond what the schema already provides, so the baseline score of 3 applies.

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

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

The description uses a clear verb+resource: it retrieves 'Customers also bought' / related apps for one app. It differentiates from sibling tools like get_app or get_app_reviews by specifying the 'similar apps' scope, and the mention of 'both stores' adds specificity.

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 fetch related apps for a given app, but does not explicitly state when to use it over alternatives or when not to use it. No sibling tools or exclusions are mentioned, leaving guidance at a basic implied level.

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?

Annotations already indicate read-only, idempotent, open-world, and non-destructive behavior. The description adds valuable operational details beyond annotations: Apple limit is clamped to 50, Google supports 1-250, price filter only applies to Google, and store='both' merges results. This is informative but not exhaustive (e.g., no mention of ordering or pagination).

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 four sentences, front-loaded with purpose, and each sentence adds distinct value: what it does, what it returns, store='both' behavior, and platform-specific caveats. No redundant words or restatements.

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 8 parameters and no output schema, the description gives a clear overall picture, including return fields and key store-specific constraints. It doesn't detail every parameter (e.g., device, fullDetail), but those are fully described in the schema, making the tool effectively invokable.

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 enriches parameter semantics by explaining the 'limit' behavior (Apple clamped vs Google range), 'store' merging behavior, and 'price' filter's Google-only scope, going beyond the schema's phrasing.

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: 'Search apps on the Apple App Store, Google Play, or both.' It identifies the resource (apps), specific stores, and lists the returned fields (store, title, developer, icon, price, rating, category, url), which distinguishes it from siblings like get_app or get_charts.

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 concrete usage context, such as using store='both' to fan out and merge results, and clarifies per-store limits. It implies when to use this tool (for general app search) but does not explicitly exclude alternatives or compare with sibling 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.