Server Quality Checklist

Tool Scores

• get_app_detailsA
  4.6/5.0
  Behavior5/5

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

  Discloses behavioral traits beyond annotations: opens a real Chromium window, requires user login, session reuse, no caching, ~10-20 second cost per app ID. Explains error handling (non-fatal per-app failures, 'not_logged_in' error) and that missing/gated fields return 'N/A'. No contradiction with annotations.

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

  Conciseness4/5

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

  Well-structured with clear sections: purpose, usage guidelines, behavioral notes, and return format. Some redundancy (e.g., 'not for Google Play' repeated). Could be slightly trimmed but overall efficient.

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

  Completeness5/5

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

  Very complete for a complex tool: provides full JSON return format, explains missing/gated fields, partial failures, use of Chromium, login flow, and performance characteristics. No output schema is needed given this level of detail.

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

  Parameters3/5

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

  Schema coverage is 100% with clear descriptions. The description adds minor context (app IDs come from 'search_app_store', must be numeric without 'id' prefix) but does not significantly extend beyond schema. Baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states it fetches SensorTower analytics for one or more App Store app IDs, listing specific data points (downloads, revenue, ratings, etc.). It distinguishes itself from siblings like 'search_app_store' (for searching) and 'research_rivals' (combined search+analytics).

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

  Usage Guidelines5/5

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

  Explicitly when to use (when app IDs are known) and when not (not for Google Play/Android). Provides alternatives ('research_rivals') and prerequisite: SensorTower account login. Also explains first-run login requirement and how to handle 'not_logged_in' error.

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

• search_app_storeA
  4.6/5.0
  Behavior5/5

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

  Beyond the annotations (readOnlyHint, openWorldHint), the description explains the return format (markdown tables), handling of missing fields ("N/A"), no-match behavior (header only), performance (no browser, ~1 second), and data limitations (no downloads/revenue). No contradiction with annotations.

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

  Conciseness4/5

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

  The description is well-structured with a clear opening, bullet points for usage, and separate paragraphs. It is slightly long but every sentence adds value, making it efficient for its purpose.

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

  Completeness5/5

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

  Given the tool has three parameters, no output schema, and annotations present, the description covers all necessary aspects: return format, error behavior, data limitations, and sibling tool references. It is fully adequate for an agent to understand when and how to use the tool.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the baseline is 3. The description does not reiterate parameter details, but the schema already thoroughly documents limit (with defaults and clamping), country (pattern), and keyword (minLength). No additional meaning is needed.

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

  Purpose5/5

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

  The description clearly states the tool searches the App Store for a keyword and returns a ranked table. It identifies the specific verb (search), resource (App Store), and output (ranked table), and distinguishes it from siblings by noting iOS-only coverage and the absence of downloads/revenue figures.

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

  Usage Guidelines5/5

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

  Explicit guidance is provided: use this to discover rankings before deep analysis, follow up with get_app_details, or use research_rivals for a combined call. It also warns against using for Google Play/Android, which effectively sets exclusion criteria.

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

• prepare_iaeA
  4.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds that the tool 'runs entirely locally: no network calls, no App Store or SensorTower lookup, and no keyword research of its own' and 'returns immediately.' This provides behavioral context beyond the annotations (e.g., local execution, no external calls) and aligns with read-only semantics. No contradiction found.

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

  Conciseness4/5

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

  The description is very long, but it is structured with headers, numbered steps, and code blocks. Every section provides necessary procedural detail (exact character limits, output format, checklist). It is front-loaded with the purpose and usage. While verbose, the complexity of the tool justifies the length, and the organization makes it scannable.

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

  Completeness5/5

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

  With no output schema, the description carries the full burden of explaining return values. It provides exact output table and final report formats, character limits, keyword placement rules, translation requirements, and the checklist. It covers every step from invocation to final output, leaving no ambiguity for an agent to execute correctly.

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

  Parameters5/5

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

  Schema coverage is 100%, so baseline is 3, but the description adds substantial semantics: it explains keyword tiering (index 0–2 = Tier 1, etc.), how locale subfields (appleCode, language, country, store) are derived, and how tone and other parameters influence copy generation. It also gives specific character limits and placement rules. This goes well beyond the schema's simple descriptions.

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

  Purpose5/5

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

  The description opens with a specific verb and resource ('Prepare an iOS App Store In-App Event') and immediately distinguishes it from ordinary listing metadata. It also explicitly excludes usage for App Store listing fields, which differentiates it from siblings like search_app_store and get_app_details. This is a clear, differentiated purpose.

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

  Usage Guidelines5/5

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

  The description gives explicit when-to-use criteria ('when the user wants to create or draft an in-app event') and when-not-to-use ('Do not use it for ordinary App Store listing metadata'). It also routes the agent to sibling tools for keyword discovery ('reach for research_rivals or search_app_store first'). This is textbook usage guidance.

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

• research_rivalsA
  4.7/5.0
  Behavior5/5

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

  Discloses caching (24h), browser opening on cache miss, login requirement, error handling for not_logged_in, time estimates, and behavior when apps fail. No contradiction with annotations (readOnlyHint and openWorldHint are consistent with reading data and client-side side effects).

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

  Conciseness5/5

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

  Well-structured with clear sections: purpose, caching, usage, prerequisites, behavior, output example, and presentation format. Every sentence adds value and it is front-loaded with the main action.

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

  Completeness5/5

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

  Covers all necessary context: complexity of combined APIs, caching, authentication, browser opening, error states, time expectations, and output interpretation. Despite no output schema, the detailed JSON example and field notes ensure completeness.

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

  Parameters3/5

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

  Schema coverage is 100% with descriptions for both parameters; the description adds minimal extra beyond schema (examples like 'psikoloji, meditation' and reaffirms country code format), so baseline 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool combines App Store search and SensorTower analytics in one call, and distinguishes from sibling tools (search_app_store + get_app_details) by specifying it is for quick overviews with 3 results.

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

  Usage Guidelines5/5

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

  Explicitly provides when to use (quick competitive overview, one step) and when not to use (need more than 3 results, custom limit, selective fetching), and notes it only covers iOS App Store.

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