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

Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds context on the information provided (breaking changes list) but does not elaborate on other behavioral traits like return format or limitations. It does not contradict annotations.

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

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

The description is dense but well-structured. It uses numbered lists and a 'Topics:' section for clarity. While somewhat lengthy, every sentence serves a purpose given the complex subject matter. It is concise enough for the information it conveys.

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 parameter and no output schema, the description provides sufficient context: what the tool does, how it differs from a sibling, and available topics. It could mention the return format, but it's not critical for a information-retrieval 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?

The single parameter 'topic' is fully described in the input schema with enumerated options. The tool description adds explanatory details for each topic, providing more meaning beyond the schema's brief list. Since schema coverage is 100%, baseline is 3, and the description adds value, a 4 is justified.

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: providing information about Android 17 API 37 compliance, specifically breaking changes not covered by android_api36_compliance. It lists specific topics, making the resource clear and differentiating it from the sibling 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?

The description explicitly mentions that it contains breaking changes NOT covered by android_api36_compliance, guiding the agent to use that sibling for API 36 changes. It also lists topics like 'overview', 'checklist', etc., providing context on when to use each. However, it does not explicitly state when not to use this 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?

Annotations already declare readOnlyHint=true, indicating the tool is a read-only reference. The description adds context about the mandatory deadline and the problem with AI-generated manifest flags, which is useful but does not disclose additional behavioral traits (e.g., response format, pagination). With annotations covering safety, the description provides adequate but not extensive 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 front-loads the essential purpose and mandatory date. It then explains the problem and lists topics. While slightly verbose (e.g., spending statistics), every sentence adds value. It could be trimmed slightly, but overall it is well-structured and efficient for the information density.

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 (1 optional parameter, no output schema) and the presence of annotations, the description is complete. It covers what the tool does, why it matters (mandatory compliance, demotion), and the available topics. No additional information is needed for an agent to understand when and how to invoke this 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?

The input schema covers 100% of parameters (topic) with a description. The description goes beyond by enumerating valid topic values: 'compliance', 'layouts', 'checklist', 'predictive back', 'page size'. This adds semantic meaning that helps the agent select the correct topic, whereas the schema's description is generic.

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: 'Android 16 compliance reference — mandatory for Google Play by August 2026.' It specifies the resource (Android 16 / API 36 compliance) and the verb (check/reference). The description distinguishes from siblings by focusing on a specific API level and problem (orientation/resizability), whereas sibling tools cover other API levels or broader Android topics.

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 needing compliance information or resolving App Compatibility warnings, but it does not explicitly state when to use this tool versus alternatives like android_api17_compliance or android_large_screen_guide. No exclusions or alternative tool names are mentioned, leaving the agent to infer the best match from the sibling list.

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 provide readOnlyHint=true, so the tool is known as read-only. The description adds behavioral context by stating it 'Returns minSdk guidance and critical API availability warnings', which is beyond the annotation. No contradictions.

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

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

The description is four sentences, no redundancy. Key information is front-loaded: the mapping function, then usage guidance, then input format examples, then the shortcut for full table. 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?

With a single parameter and no output schema, the description fully explains what the tool does, what inputs it accepts, what outputs it returns (minSdk guidance, warnings), and how to use it. No gaps remain for an agent to misuse the 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 a description that already lists valid inputs. The description adds the extra valid value 'table' (and 'all') beyond what the schema says ('all' but not 'table'), and clarifies the purpose of the parameter for validation. This adds 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 begins with 'Maps Android API levels to version names, codenames, and key feature availability', providing a clear verb+resource+scope. It distinguishes itself from sibling tools like android_api17_compliance and android_api36_compliance by focusing on reference mapping rather than compliance checking.

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 'Use this to validate that the APIs you plan to use are available at your project's minSdk', giving clear context. It does not mention when not to use or name alternatives, but the sibling tools imply alternatives for compliance checks.

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, indicating a safe read operation. The description adds specific behavioral context by enumerating the topics covered (e.g., R8, signing, baseline profiles), clarifying what information the tool provides.

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 relatively long (over 90 words) and includes a bullet-like list of topics. While it front-loads the purpose, the list adds verbosity. It could be more concise by grouping related topics or using a summary.

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 complexity of a reference tool with one optional parameter and no output schema, the description adequately covers the scope of topics but does not describe the output format or behavior when no topic is provided. It is complete enough for a read-only reference.

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 the single parameter 'topic' with examples. The tool description adds only a few example values but does not provide additional semantic 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 clearly identifies the tool as a complete Android build pipeline and Play Store publishing reference, listing specific topics like R8, ProGuard, Gradle Version Catalogs, etc. This distinguishes it from sibling tools that focus on other aspects like API compliance or testing.

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 build and publishing questions but does not explicitly state when to use this tool versus siblings like gradle_dependency_checker or android_official_search. No when-not 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?

The description discloses the tool's read-only nature (consistent with readOnlyHint: true), return structure (verdict, violations with replacements and doc URLs), and next-step instructions on handling FAIL verdicts. It also notes language auto-detection, exceeding annotation info.

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 front-loaded with a critical usage instruction and structured to cover purpose, return, and inputs. While slightly lengthy, each sentence contributes necessary 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?

Despite no output schema, the description fully explains return values (verdict, violations with replacements and doc URLs) and behavior (auto-detection, SDK context). It covers all necessary aspects for a complex validation 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?

With 100% schema coverage, baseline is 3. The description adds value by explaining auto-detection for 'language' and 'context-aware API level checks' for SDK parameters, going beyond schema 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 the tool validates AI-generated Android code against 24 rules, distinguishing it from sibling compliance and guide tools. It specifies the languages (Kotlin, XML, Gradle) and types of issues detected (removed APIs, deprecated patterns, Android 16 violations).

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 instructs to call this after every generated code block, providing strong usage guidance. However, it does not mention when not to use it or offer alternatives, though the sibling list implies its specific role.

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?

Read-only annotation is consistent with description. Description adds valuable behavioral context: it prevents use of removed/deprecated APIs, and lists known failures. No contradictions.

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

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

Single paragraph with clear front-loading of purpose and usage. Could be slightly more structured (e.g., bullet points) but no unnecessary sentences.

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?

Covers purpose, usage, examples, and return info (status, replacement, migration notes, link). Lacks details on return format or error handling, but sufficient for a simple validation 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 already fully describes parameter with 100% coverage. Description reinforces example values but does not add new semantic information beyond 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?

Clearly states it checks stability/deprecation/removal of Android/Kotlin components. Distinguishes from sibling tools like android_api_level_check by focusing on API status rather than API level. Provides specific examples of known failures.

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 to call before using any class from android.*, androidx.*, or kotlin.*. Provides context about AI tool failures and lists specific examples of removed/deprecated APIs.

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, so the description adds value by detailing behavioral traits: parsing stacktraces, returning parsed error class, official explanations, and vetted fixes. It also includes a quality promise ('Never guess'), enhancing transparency beyond the annotation.

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 consists of three purposeful sentences: the first states the main action, the second provides input instructions, and the third summarizes output and quality promise. No extraneous words, and 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 simple tool with one parameter, no output schema, and a read-only annotation, the description fully covers what the tool does, how to use it (input format), and what results to expect (parsed error, explanations, fixes). It is complete and leaves no ambiguity.

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% for the single parameter 'stacktrace', and its description already explains the input format. The tool description reiterates this ('Paste the full crash log or exception') but adds no new meaning beyond the schema, earning a baseline score 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 parses Android/Kotlin stacktraces and searches official sources for causes and fixes. It specifies the input (full crash log) and output (parsed error class, explanations, vetted fixes). This distinguishes it from sibling tools, none of which focus on stacktrace debugging.

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 instructs users to paste the full crash log or exception, implying use when a stacktrace is available. It explicitly grounds debugging in official sources. While it does not list when not to use or alternative tools, the clear context and unique functionality make it effective.

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 mark the tool as read-only (readOnlyHint=true). The description adds valuable behavioral context by warning about common code generation pitfalls and listing what topics are covered, without contradicting 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 front-loaded with the core purpose and critical warnings, making it efficient despite its length. Every sentence adds value (e.g., library lists, pitfalls), but it could be slightly more 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?

Given the tool is a guide with a single parameter and no output schema, the description provides a thorough overview of its content and constraints. It covers all necessary context for an agent to understand its use.

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% as the single parameter 'topic' is fully described with allowed values. The description repeats those topics but does not add new semantic details beyond what the schema provides, so 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 it is a 'Complete Kotlin Multiplatform reference' that shares business logic across Android and iOS. It distinguishes itself from sibling tools (e.g., android_testing_guide, material3_expressive) by focusing specifically on KMP and providing unique warnings about common pitfalls.

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 includes critical usage warnings (e.g., 'AI tools silently generate Android-only code', 'Retrofit cannot be used in KMP'), which guide when to use alternatives. While it doesn't explicitly state when to use this tool vs siblings, the context of KMP guidance is clear and well-supported.

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, indicating safe read-only operation. The description reinforces this by calling it a 'reference,' but does not add additional behavioral context like rate limits, authentication needs, or output format. The description does not contradict annotations.

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

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

The description is a single paragraph that front-loads the main purpose and lists key topics. It is reasonably concise, though a few more sentences could be trimmed without losing value. Keywords at the end aid scanning.

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 (a reference guide) and the simple input schema (one optional param with no output schema), the description adequately covers what the tool does and how to use it. It could mention the return format (e.g., returns text/guidance) but is otherwise complete for an agent.

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% (one param with description). The description adds extra meaning beyond schema by listing example topics (e.g., 'windowsizeclass', 'NavigationSuiteScaffold') and explicitly stating 'Leave empty for index,' which helps the agent know how to use the parameter effectively.

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 is a complete reference for building Google Play-compliant large screen apps, covering specific topics like WindowSizeClass, two-pane navigation, and foldable detection. It distinguishes itself from sibling tools by focusing on large screen and adaptive layouts, with explicit scope (tablets, foldables, ChromeOS).

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 explicit when-to-use guidance: 'Call before building any multi-screen layout, navigation, or when targeting tablets and foldables.' However, it does not mention when not to use this tool or suggest alternative sibling tools, such as android_navigation3_guide or android_scalability_guide.

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 adds context that the tool is a 'stable reference' and is safe to call (no destructive actions). Annotations already mark it as read-only, so no contradiction. The description effectively reinforces the non-destructive nature.

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 well-structured with a clear opening, critical warning, and topic breakdown. It is slightly lengthy but every sentence adds value. Could be slightly more concise, but overall effective.

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 implies return of reference text but does not explicitly describe response format. However, it covers essential usage context, topic options, and guidance, making it largely complete for a reference 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 a brief parameter description; however, the tool description adds rich detail for each topic value (e.g., 'overview' includes setup, NavKey, etc.; 'migration' includes API mapping). This significantly aids correct parameter selection 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 it is a 'Complete Navigation 3 reference' and specifies the library version and purpose. It differentiates from sibling tools by emphasizing it is the current official navigation library and explicitly lists covered topics.

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 instructs 'ALWAYS call this before generating any navigation code' and warns against hallucinating Navigation 2. It provides a clear when-to-use guidance and lists specific topics to request.

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 adds context beyond the readOnlyHint annotation by specifying it returns official excerpts and source URLs, and emphasizes it is a safe, read-only operation.

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 concise sentences with front-loaded 'REQUIRED FIRST STEP' and example queries. 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?

The description is complete for a search tool: it explains what data sources are searched, what is returned, and how to use it effectively. No output schema needed.

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 has 100% coverage for the single 'query' parameter with a good description. The tool description supplements with example queries and guidance to be specific, adding 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 the tool searches multiple official documentation sites for Android/Kotlin topics and returns excerpts with URLs. It is distinguished from sibling tools by being the general search required as a first step.

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 states 'REQUIRED FIRST STEP' and that it must be called before generating any Android/Kotlin code, with example queries. However, it does not explicitly mention when to use alternative 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?

Annotations declare readOnlyHint=true, and the description reinforces no side effects by characterizing it as a reference that 'works offline' and involves no network round-trip or API costs. No contradiction.

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

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

The description front-loads the purpose and includes structured topic list with bullet-like formatting. While verbose, every sentence adds context, and the length is justified given the breadth of 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 guide tool with one optional parameter and no output schema, the description covers what it does, its architecture, use cases, and topic details. It is complete enough to inform invocations, though return format is not specified (acceptable).

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 a parameter description listing valid topics. The description expands this by adding parenthetical explanations for each topic ('architecture pattern', 'dependencies, availability check' etc.), providing extra 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 it is an 'On-device AI reference' for Android 16 AICore and ML Kit, with concrete examples (Gmail Smart Reply, Google Photos object detection) distinguishing it from sibling tools covering compliance, debugging, or building.

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 explains contexts like offline and privacy as reasons to use on-device AI, and contrasts with cloud API defaults. While it doesn't explicitly list exclusions, the topic list ('overview', 'setup', etc.) guides when to invoke.

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, so the description doesn't need to reinforce safety. It adds value by specifying what data is returned (type, runtime request, etc.) without contradicting annotations. No contradiction 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 a single, well-structured paragraph. It front-loads the purpose, then details return information, examples, and a special query. No redundant or wasted sentences.

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 absence of an output schema, the description thoroughly explains the return values and even includes a special query for runtime pattern. It covers all necessary contexts for a single-parameter, read-only 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 a clear description of the 'permission' parameter, including examples and special query hints. The description adds examples and usage guidance, but the schema already carries the semantic weight, so a 4 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 it is a 'Complete Android permissions reference' and lists the specific information it returns (type, runtime request, Play Store restrictions, request pattern). This distinguishes it from sibling tools like android_api_level_check or android_play_policy_advisor.

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 says 'Call before declaring any <uses-permission> in AndroidManifest.xml,' providing clear when-to-use guidance. While it doesn't mention when not to use or explicitly name alternatives, the context is strong enough for an agent to understand its role.

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 declare readOnlyHint=true, which matches the description's reference nature. The description adds context about AI unawareness of policy changes and consequences (weeks of re-submission), which exceeds 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 well-structured with a clear overview, specific topics, and usage instruction. It is longer than minimal but every sentence adds value, including caveats about AI awareness and real-world impact.

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 policy reference tool with one parameter and no output schema, the description adequately explains its purpose, topics, and use cases. It could briefly mention the response format, but overall it is 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 covers 100% of parameters with a description for 'topic' listing allowed values. The description adds semantic context for each topic (e.g., 'mandate timeline' for overview, 'billing transparency code' for subscriptions), enriching the schema's information.

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 a Play Store policy reference covering October 2025 changes and ongoing requirements. It lists specific topics (e.g., Restrict Minor Access API, subscription transparency) and distinguishes from sibling tools like android_permission_advisor or android_large_screen_guide by focusing on policy compliance and submission

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 'Call before submitting any app to Play Store or adding new monetization features,' providing clear context for when to use. It does not list exclusions or alternatives, but the sibling list implies differentiation.

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 include readOnlyHint=true, and the description aligns as a read-only guide. No contradictions. The description fully discloses the tool's purpose without hiding any destructive 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 front-loaded with purpose and well-structured, listing topics concisely. A bit long but every sentence adds value, making it 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 the complexity of scalability architecture, the description covers key topics and usage context. Without an output schema, it sufficiently explains what the guide provides.

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 a description for the topic parameter. The description adds value by listing example values and noting to leave empty for index, which helps 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 it provides architecture patterns for Android apps at scale, listing specific topics like Paging 3, offline-first, etc. It distinguishes itself from sibling tools such as android_kmp_guide or architecture_reference by focusing on scalability.

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 'Call before designing data layers, list screens, sync mechanisms, or module structure,' giving clear context on when to use. It does not explicitly mention when not to use or list alternatives, but the guidance 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?

Annotations declare readOnlyHint=true, which the description aligns with by presenting the tool as a reference. The description adds value by detailing the topics covered (e.g., unit tests, compose testing, espresso, hilt testing) and implying the tool returns information based on the optional topic parameter.

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 dense with information but slightly redundant (list appears twice). It is front-loaded with the core purpose and topics, making it efficient for an agent to parse.

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 reference tool with one optional parameter and no output schema, the description adequately explains functionality, topics, and calling context. It could specify the return format (e.g., text or markdown) but is otherwise 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 covers 100% of parameters and includes a description for 'topic'. The description adds extra guidance: 'Leave empty to list all.' This enhances usability beyond the schema alone.

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 is a 'Complete Android testing reference' and lists specific topics (unit tests, Compose UI, Espresso, etc.), with an explicit call to action: 'Call before writing any test.' This distinguishes it from sibling tools, which are other Android guides (e.g., large_screen_guide, navigation3_guide) not focused on testing.

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 includes when to use the tool ('Call before writing any test'), providing clear context. However, it does not explicitly mention when not to use it or alternative tools, though no direct testing alternative 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?

Annotations declare readOnlyHint=true, which the description does not contradict. The description adds behavioral context by framing the tool as a reference guide and detailing the content coverage (e.g., critical differences, specific topics).

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 front-loaded with the tool's purpose and critical warnings, followed by a list of topics. It is somewhat lengthy but each sentence adds information. Could be slightly more concise without losing clarity.

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 breadth (multiple topics), the description provides sufficient context for a developer to understand its scope and content. No output schema is needed for a guide, and the description covers essential aspects.

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%, yet the description enriches the 'topic' parameter by elaborating on each option (e.g., 'compose' covers ScalingLazyColumn, Chip, navigation). This adds value beyond the schema's brief 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 identifies the tool as a 'Wear OS development reference' with specific topics (Wear OS 5, Material 3 Expressive) and distinguishes it from other Android guides (e.g., android_large_screen_guide, android_xr_guide) by focusing on Wear OS-specific components and APIs.

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 Wear OS development by contrasting phone Compose with Wear Compose and listing correct components. It does not explicitly state when not to use it, but the sibling tool names indicate alternative guides for other Android topics.

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 declare readOnlyHint: true, so the description does not need to reiterate safety. It adds valuable behavioral context, such as the temporal status ('Developer Preview 3, December 2025'), device release info, and a caution about AI-generated code missing spatial value. 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 verbose, containing multiple paragraphs and extra details (e.g., launch dates, device counts) that go beyond core guidance. While the first sentence front-loads the purpose, the extraneous information reduces conciseness. Some sentences could be removed without losing essential meaning.

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 (a reference guide with one parameter, no output schema), the description is remarkably complete. It covers the purpose, topics, technical notes (Material 3 auto-spatial, AI code limitations), and compatibility patterns. An AI agent would have a thorough understanding of what to expect 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.

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

The schema covers the 'topic' parameter with 100% coverage, listing five valid topics. The description enriches this by providing detailed context for each topic (e.g., 'overview: concepts, device status'; 'spatial ui: SpatialPanel, UserSubspace, Orbiter'). This adds significant meaning beyond the schema's simple enumeration.

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 is an 'Android XR SDK reference' and lists specific topics like 'overview', 'setup', 'spatial ui', 'arcore', and 'compatibility'. The name and title are descriptive and distinguish it from sibling tools (e.g., android_large_screen_guide, android_wearos_guide) by focusing solely on XR.

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 explains when to use this tool (for XR-specific development) and contrasts it with generic Compose development (e.g., 'Standard Compose apps run as 2D panels on XR headsets — no SDK required'). However, it does not explicitly state when not to use it or compare directly with sibling tools, leaving some ambiguity for an AI agent.

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 provide readOnlyHint=true. Description adds that it retrieves content but does not add further behavioral detail (e.g., response format, caching). Adequate but no extra transparency 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?

Two sentences, front-loaded with action, then usage guidance and topic list. No unnecessary words. Highly 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 simple retrieval tool with one parameter, the description covers when to use, supported topics, and the 'list' option. It lacks detail about the output format but that is typical for a guide retrieval. Complete enough given the tool's 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 coverage is 100% and the schema description is already comprehensive. The tool description reiterates the parameter but adds little new meaning. 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?

Clearly states 'Retrieves official Android architecture guide content for a given topic.' with specific verb and resource, and distinguishes from many sibling guides by focusing on architecture.

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 says to 'Call this before proposing any app architecture, folder structure, or Jetpack component relationships,' providing clear context for use. Does not mention 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?

Annotations include readOnlyHint: true. Description reinforces read-only nature and adds behavioral details like known failures (e.g., wrong Coil group, missing BOM wrapper). No contradictions. Slightly above baseline due to additional context.

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?

Description is a single concise paragraph, front-loaded with purpose. Contains useful details but could be more structured (e.g., bullet points). Not verbose, but not maximally 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?

Tool has one parameter and no output schema. Description fully explains input examples and output format: 'latest stable version, ready-to-paste Kotlin DSL, BOM resolution, KMP vs Android distinction.' Sufficient for the agent to understand inputs and outputs.

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?

Input schema has one parameter 'library_name' with minimal description. The description provides extensive examples and contextual notes about expected values (e.g., 'compose', 'hilt') and return details (BOM, KMP distinction). This adds significant value beyond schema, but schema coverage is 100%, so baseline 3, justifying 4.

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 it is a 'Live version lookup for any Android, Kotlin, or Jetpack library from Google Maven and Maven Central.' The verb 'lookup' and resource 'latest stable version' are specific. It distinguishes from sibling tools by focusing on dependency version checking.

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?

Explicit instruction: 'ALWAYS call this before adding or updating any dependency in build.gradle.kts.' Provides examples and known failures, aiding the agent in when to use. However, does not explicitly state when not to use or mention alternatives, so not 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?

Annotations declare readOnlyHint=true, and the description is consistent (returns patterns, no modification). The description adds value by specifying the source (developer.android.com and kotlinlang.org) and listing available patterns, enhancing transparency 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 a single, well-structured paragraph with no wasted words. It front-loads the main action, then provides usage triggers, sources, and parameter guidance, making it efficient and easy to parse.

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 (one optional parameter, no output schema, read-only), the description is comprehensive. It covers purpose, usage conditions, parameter semantics, and reliability sources, leaving no significant gaps for an agent.

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 a description for the 'topic' parameter. The tool description adds examples ('coroutines', 'compose state') and clarifies that leaving it empty lists all patterns, providing meaningful context 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 returns official Kotlin and Android code patterns with snippets and anti-patterns, specifying the verb 'returns' and resource 'code patterns'. It distinguishes from sibling tools (e.g., compliance, debugging) by listing specific pattern categories and use cases.

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 when to call the tool (e.g., when generating coroutine code, Compose state, Room DAOs) and how to use the topic parameter, including leaving it empty to list all patterns. It does not explicitly mention when not to use it or alternative tools, but the guidance is clear enough.

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. Description adds content scope but no additional behavioral detail. Compliant with annotations, no contradiction.

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

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

Front-loaded with purpose, then lists topics. Somewhat lengthy but each sentence adds value. Could be slightly more concise, but structure is logical.

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?

Covers all mentioned topics and use cases. No output schema, but description of topics is sufficient for an agent to understand what to query. Lacks details on output format, but acceptable for a reference 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 baseline is 3. Description repeats the parameter guidance ('Leave empty to list all topics') but doesn't add new 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?

Description clearly states it's a complete reference for M3E and instructs to call before building Compose UI. Differentiates from siblings by its specific focus on Material 3 Expressive design system.

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 says 'Call this before building any Compose UI or theming', providing clear when-to-use context. No explicit alternatives or when-not-to, but siblings are other Android tools, so it's implied.

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