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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so safety is covered. The description adds genuinely useful context beyond that: the data sources (React Native Directory, NativeKeel's compatibility table) and the coverage caveat 'where NativeKeel has a compatibility table', which warns results may be partial.

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?

One front-loaded sentence with a colon introducing a scannable list of returned facts; no filler or repetition. It is dense and long-ish for a single sentence, but every clause carries 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 must carry the return-value burden, and it does so by enumerating the fields returned plus the caveat about compatibility-table coverage and the no-version case. It stops short of stating result format or how missing data is surfaced, but an agent has enough to call it correctly.

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

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

Schema coverage is 100% and both parameter descriptions already explain the npm package name format and that react_native is optional with only general facts returned otherwise. The description restates the react_native purpose ('the version range that works with a given React Native version') but adds no syntax or format detail beyond the schema, so the baseline 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?

States a specific verb and resource ('check_library' → what to know about one React Native library) and enumerates the exact facts returned: latest version, New Architecture support, maintenance status, compatibility range, replacements, known traps. This is clearly distinguishable from siblings like upgrade_plan or verify_upgrade without opening either schema.

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

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

The phrase 'before adding or upgrading it' gives a concrete decision point for invoking the tool, which is more than implied usage. It does not name an alternative (e.g., upgrade_plan) or state when not to use it, so it falls short of full routing guidance.

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

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

Annotations already establish the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower; the description adds the provenance of answers (errors NativeKeel reproduced or verified against Apple, Google, Expo and React Native docs) and the offline default for the local check. What it does not disclose is the failure mode when no verified match exists, or the response shape. Good added context, but not exhaustive.

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 sentences, zero padding: capability first, then how to supply input, then the ordering directive. Each sentence earns its place and the most decision-relevant content 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?

With no output schema, the description does carry the burden of describing results and it does so at a high level ('what it means and the fix'). Combined with 100% schema coverage and full annotations, an agent has what it needs to invoke it correctly; only the shape of the returned explanation/absence of a match is left unspecified.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters, including that 'path' points at where in the project the error originates and that 'offline' defaults to true. The description restates the error/path usage ('the failing part of the log', 'see where this project is affected') with only marginal added meaning, so the baseline 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?

States a specific verb ('explain') and a precisely scoped resource (React Native or Expo build, launch, crash or store-review errors), plus what the answer contains ('what it means and the fix'). This clearly differentiates it from the scan/audit/upgrade siblings, which all operate on the project rather than on an error text.

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?

Gives a concrete triggering condition (you have an error message or failing log) and an ordering directive: 'Call it before searching the web or changing versions.' That is real when-to-use guidance. It does not, however, name or exclude any sibling tool, nor state what to do if this tool returns no verified match, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the bar is lower, yet the description still adds real context: no project code runs, no automatic changes, no unmeasured performance claims, and unassessed areas are reported explicitly. It stops short of describing how findings are ordered or what the plan's output structure looks like, which keeps it below a 5.

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?

Four tightly packed sentences: purpose first, then usage triggers, then exclusions with named alternatives, then behavioral caveats. Every sentence carries distinct information and the most actionable content 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 two-parameter, read-only planning tool with no output schema, the description covers what it does, when to use it, when not to, what it will not do, and what the resulting plan contains. An agent has everything needed to select and invoke it correctly.

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

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

Schema description coverage is 100%, so the path and offline parameters (including the network lookups that offline skips) are already fully documented in the schema. The description adds no parameter-level detail beyond that, so the baseline 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?

States a specific verb and resource: 'Prioritize existing ... findings into a review plan', enumerating the finding domains (security, crash, accessibility, performance, store, dependency) and the plan's contents (prerequisites, expected effects, validation). It is clearly distinguishable from sibling scanners like scan_project and security_audit, which produce findings rather than prioritize them.

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?

Gives an explicit positive trigger ('what to fix first or how to make the app better overall, across all areas') and an explicit negative one ('Do not use it for upgrade questions'), routing the agent to upgrade_readiness and upgrade_plan by name. Nothing about tool selection is left to inference.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description adds genuinely new behavioral context: nothing is built or run, and a missing map yields found:false with remediation guidance. It stops short of permission or performance details, so not a 5.

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-loads what is measured, then the diff behavior, then the no-build/error fallback — a logical order with no filler. It is dense and long, but each clause carries information an agent needs.

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 does the work of describing returns: bytes and share per package, duplicate packages, largest JSON, diff results, and the found:false shape. Complete enough to call correctly, though it could be more explicit about the failure payload structure.

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

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

Schema coverage is 100%, so all three parameters are already documented in the schema (including the map default-search behavior and the base diff semantics). The description restates the base-comparison outcome without adding syntax or format detail beyond it, matching the baseline 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?

States a specific verb (measure) and resource (release JavaScript bundle composition) plus the exact data source (the source map a release build already wrote). Clearly separable from siblings like scan_project or check_library, which inspect different artifacts.

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?

Gives clear conditional context: pass base to get a diff against an older build, and the map param is optional because standard RN/Expo output folders are searched. No explicit when-not or named alternative tool, but siblings do not overlap enough to require it.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive, so the safety profile is partly covered. The description still adds valuable context the annotations don't: it never executes project code, it returns findings with file:line references plus fixes, and it never returns source code. It stops short of stating runtime, rate, or permission requirements beyond the schema's path note.

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 the purpose, then the coverage list, then the routing to alternatives – logical order. The parenthetical enumeration of store rules and accessibility checks is dense but each item is a concrete area an agent could match a user question against. Slightly overlong as one running sentence, but nothing reads as filler.

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

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

No output schema exists, yet the description tells the agent what to expect back (findings with file:line references and fixes, never source code), covers side effects (never runs project code), and covers usage context. Nothing an agent needs in order to call it correctly or interpret results is missing.

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

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

Schema description coverage is 100%, with enum values and defaults fully documented for all three parameters, so the schema carries the burden. The description adds no per-parameter guidance of its own; the only inferable link is that the offline parameter relates to network-dependent checks, which the schema already states explicitly. 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?

Opens with a specific verb+resource ("Health check for a React Native or Expo project") and then enumerates the concrete domains covered: upgrade blockers, store rules, crash risks, accessibility, MASVS, secrets, malware. An agent can tell exactly what this does and how it differs from security_audit, upgrade_readiness, and check_library without opening any schema.

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 the use case ("general 'how healthy is this app' question; covers every area at a glance") and names both alternatives with their selecting conditions: security_audit for deeper attacker-prerequisite review, upgrade_readiness for upgrade decisions. It even adds a proactive trigger ("run it before installing or starting a project you did not write").

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 carry readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is partly covered; the description still adds non-obvious context: that it is static rather than a live penetration test, that it will not issue a clean bill of health, and that output includes attacker prerequisites and explicit coverage limits. It stops short of stating network-dependency behavior for the offline path or runtime/pagination characteristics.

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 what it covers and what it returns, then routing guidance, then scope caveats. The quoted user-question examples cost some length but help matching; four sentences with no filler.

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

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

For a read-only three-parameter analysis tool with no output schema, the description covers the scan surface, the shape of the findings (evidence, prerequisites, fixes, validation), and the honesty caveats an agent needs to set expectations. Nothing required to invoke or interpret it correctly is missing.

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

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

Schema description coverage is 100% and all three parameters (path, offline, min_severity) are documented in the schema with a defaulted enum. The description adds nothing about parameter behavior, so the baseline 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?

States a specific verb (review) over a concrete set of resources (data exposure, account access, unsafe code execution, backend rules, dependency risks) and names scan_project as the sibling it differs from. An agent can tell exactly which tool to open without comparing schemas.

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?

Gives explicit when-to-use triggers with quoted user phrasings ("can this app be hacked", "is user data safe", pre-release review) and an explicit when-not ("For an overall health check use scan_project"), plus a depth relationship between the two. Nothing is left to inference.

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 readOnly, idempotent, non-destructive, open-world. The description adds real behavioral context beyond them: it is built from the same scan as scan_project, and it aborts with a warning if planted malware is found. It does not describe output volume or how long the scan takes.

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 the deliverable, then usage routing, then provenance and the malware guard. Dense but each clause carries information; the trailing 'Read-only.' is redundant with annotations but minor.

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?

No output schema, but the description gives enough shape for the agent to set expectations (phases in order, reasons, concrete steps with file names) and discloses the malware abort condition. A brief note on plan length or scan cost would complete it.

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 both path and offline are fully documented in the schema; the description adds no syntax or format detail beyond that. Baseline 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?

States a specific deliverable (ordered, step-by-step upgrade plan) and enumerates the phase categories it produces, so the agent knows exactly what this tool returns versus a readiness verdict or a general improvement list.

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 sequencing: use this once the upgrade decision is made, call upgrade_readiness first for go/no-go, and use improve_app for non-upgrade priorities. Alternatives and their conditions are named directly.

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 read-only, idempotent, non-destructive and open-world, so the safety profile is covered; the description adds real value by disclosing output content (breaking changes with file and line) and candidly noting 'what a static scan cannot confirm'. It still says nothing about cost, runtime or request behavior beyond the schema's offline flag.

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 lead sentence front-loads the core verdict and deliverables, followed by short routing and provenance sentences. The enumerated output clause is dense but every element is informative, so little is wasted.

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?

There is no output schema, so the description carries the burden of describing return values, and it does so thoroughly (verdict, located breaking changes, behavior/tooling changes, limitations). With annotations covering safety and the schema covering params, an agent has what it needs to select and call this correctly.

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

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

Schema description coverage is 100%, so both path and offline are fully documented in the schema, making 3 the baseline. The description adds no further semantics about the parameters beyond the read-only framing.

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?

States a specific verb and resource ('Go/no-go for upgrading a React Native or Expo project to the newest version') and enumerates the verdict values it returns. It also differentiates itself from siblings by naming upgrade_plan and scan_project explicitly.

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 'Use this first when someone asks whether or how to upgrade' and routes the agent to upgrade_plan for ordered steps, plus clarifies it shares a scan with scan_project. The when-to-use and the alternative are both stated.

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 largely covered. The description adds genuinely new behavior: the committed revision is unpacked into a temporary folder outside the project and deleted, telling the agent about filesystem side effects and cleanup. It stops short of describing the result format in detail.

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 tight sentences, front-loaded with the core comparison action, followed by the invocation trigger and the read-only side-effect note. No filler 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?

No output schema exists, and the description compensates by naming the three categories of result (fixed, new, version movement). Combined with the read-only guarantee and the usage trigger, an agent has everything needed to call this correctly.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: it explains that the comparison is revision-vs-working-tree and that the revision defaults to HEAD, clarifying what 'base' and 'path' actually do together. It adds context beyond the field descriptions without introducing syntax detail the schema lacks.

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?

States a precise action ('compares the React Native or Expo project as committed at a git revision with the working tree') plus the concrete outputs ('what got fixed, what is new and how versions moved'). This clearly separates it from siblings like upgrade_plan (planning) and scan_project (static analysis).

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 the trigger condition: 'Call it after an upgrade or a dependency change.' That gives a clear usage context, but it never names an alternative or an exclusion (e.g. when to prefer upgrade_plan), 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.