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

With no annotations, the description carries the burden of disclosure. It usefully states that the build uses the existing local Android SDK/JDK and returns source and APK hashes, but it does not describe side effects such as artifact output location, overwrite behavior, or failure handling.

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

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

The description is two tight sentences with the core action front-loaded. Every sentence contributes useful information without redundancy.

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

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

For a zero-parameter tool with no output schema, the description covers the essential action, environment, and return values. It could say more about build outputs or failure behavior, but the core invocation context 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?

The tool has zero parameters, so there is no parameter semantics to explain. The description appropriately focuses on what the tool does and returns rather than compensating for a parameter schema.

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

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

The description states a specific verb and resource: it builds the diagnostic Camera2 APK. It also names the build environment (local Android SDK/JDK) and the return value (source and APK hashes), making it clearly distinct from sibling tools like run_camera_validation or read_source_file.

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 no explicit guidance on when to use this tool versus alternatives, nor does it state when not to use it. The implied usage is build-related, but there are no routing cues or workflow context.

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

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

Annotations only declare destructiveHint=false; the description adds real behavioral context — no push, rejection of unrelated staged files, and hard exclusions for IMG_ENHANCE/TTC. It stops short of stating auth requirements, return values, or failure 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?

A single tight sentence with the core action first and the negative constraints trailing. 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?

For a mutation tool with no output schema and zero parameter descriptions, the description covers scope and prohibitions but omits prerequisites (staging), success/failure outcome, and message semantics. Adequate but with visible gaps.

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 0%, so the description must carry parameter meaning. It clarifies 'files' means individual Genio source files listed explicitly, but says nothing about the 'message' parameter or the 80-file/2000-char limits. Partial compensation for the coverage gap.

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?

Specific verb (commit) plus precise resource scope: 'exactly the listed individual Genio source files'. It is clearly distinguishable from the read/edit/diff siblings (edit_source_file, get_source_diff, list_source_files) which do not commit.

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 exclusions: never operates on IMG_ENHANCE or TTC, never pushes, refuses unrelated staged files. This tells the agent when the tool will reject a call, but it never names an alternative tool or the positive precondition (files must be staged) 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 only declare destructiveHint=false; the description adds real value beyond that by asserting 'never deletes files', the write opt-in requirement, and exclusive-create semantics for NEW. It does not explain the failure mode on a SHA mismatch or what happens when old_text is non-unique, both of which matter for an editing tool.

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

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

Three dense sentences with the edit mechanism front-loaded and the create variant and safety caveats following. No filler, though the 'NEW creates a file exclusively...' sentence is terse enough to be slightly ambiguous about the exclusive-create failure behavior.

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

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

For a mutation tool with no output schema and minimal annotations, the description covers the essential behaviors: hash precondition, opt-in write permission, no-delete guarantee, and create-vs-edit modes. It stops short of describing return values or error conditions, which are left entirely 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 coverage is 0%, so the description must carry the parameter burden. It clarifies expected_sha256 (from read_source_file) and content (used by NEW mode), and implies replacements via 'exact unique replacements', but never covers path or explains that expected_sha256 is required even in create mode.

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 ('Edit one source file') plus the mechanism (exact unique replacements, SHA256 from read_source_file), and covers the create-new variant. It references the relevant sibling for obtaining the hash, but does not distinguish itself from commit_candidate or explain the read→edit→commit relationship.

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 preconditions: use the SHA256 returned by read_source_file, and a source write opt-in is required. It does not state when-not to use it, e.g. what separates this from commit_candidate or how it interacts with the broader candidate workflow.

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 safe read behavior is covered. The description adds a useful semantic caveat that availability is distinct from verified control effects, but it does not disclose permissions, rate limits, or return characteristics beyond that.

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

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

Two short sentences, front-loaded with the action and resource, followed by the key caveat. Every sentence earns its place 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 no-parameter read tool with no output schema, the description gives enough to call it correctly: what it reads and a critical distinction about the data. It could be more complete by hinting at the shape of returned metadata, but the essential context is present.

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

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

The tool takes zero parameters, so the schema has no parameter semantics to explain. Baseline for 0 params is 4; the description does not need to add parameter details.

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

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

The description states a specific verb and resource: 'Read HAL-advertised camera metadata.' It also distinguishes this from validation by noting 'Availability is distinct from verified control effects,' which differentiates it from run_camera_validation without naming the sibling 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?

The second sentence implies usage: call this for advertised metadata, not for verified control effects. However, there is no explicit statement of when to use this tool versus alternatives like build_camera_probe or run_camera_validation, leaving routing 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 readOnlyHint=true, so the safety profile is covered. The description adds the useful behavioral trait that the job is asynchronous, implying non-terminal statuses, but says nothing about terminal states, polling, expiry, or error conditions.

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 short sentence with no filler and the resource front-loaded after the verb. It is efficient, though it is arguably terse to the point of under-specification rather than maximally helpful.

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 and no annotation detail beyond readOnlyHint, so the description should carry more of the load. It does not describe what status values are returned or how to obtain a job_id, leaving an agent with real gaps for a job-polling 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 has 0% schema description coverage; the schema only supplies a regex pattern. The description does not explain where job_id comes from (e.g., returned by build_camera_probe or run_camera_validation) or what form it takes, so it fails to compensate for the coverage gap.

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 clear verb ('Read') and resource ('asynchronous build/capture job status'), which is specific enough for an agent to know it fetches job state. It does not differentiate itself from siblings such as get_report, so it falls short of a 5.

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 word 'asynchronous' faintly implies this is polled after launching a build/capture job, but there is no explicit when-to-use, when-not-to-use, polling cadence, or named alternative. It sits at the same level as a bare 'update settings' style description.

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 readOnlyHint annotation already declares this a safe read, so the description's lower bar is met. It adds one useful behavioral fact — the default response is a summary — but does not disclose what the full report contains, what "artifact paths" resolve to, or any failure modes.

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

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

Two short, front-loaded sentences with no filler; the core purpose leads and the default behavior follows. It is efficient, though the trailing "and artifact paths" fragment is slightly imprecise rather than fully earning 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 no output schema, the description carries some return-value burden and does indicate a summary vs. full report. But it leaves "local validation report" undefined, never ties run_id to a prior validation run, and gives no guidance on report availability or staleness — adequate but with clear gaps for a read tool in an 11-tool family.

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 0%, so the description must compensate. It does partially: "Summary is the default" explains the `full` flag's default and intent, which the schema only shows as a bare boolean. But `run_id` is left entirely to its name and pattern, and the relationship between `full` and the summary default is only implied.

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 names a specific verb and resource ("Read a local validation report and artifact paths"), so the operation is identifiable. However it does not distinguish itself from siblings such as get_job or run_camera_validation, and "artifact paths" is a stub rather than a clear statement of scope, so it stops short of a 5.

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?

"Summary is the default" hints at output behavior but gives no when-to-use guidance, no prerequisites, and no routing relative to the many sibling tools (get_job, run_camera_validation, list_source_files). An agent gets no help deciding whether this is the right tool or when to set full=true.

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 readOnlyHint annotation already establishes safety, and the description adds real value by disclosing what the response contains (status, unstaged, and staged changes) — important since there is no output schema. It does not mention size limits or behavior when a file has no changes, but the core behavioral picture is covered.

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 sentence with no filler, front-loaded with the verb and the scope, and every clause contributes — the staged/unstaged distinction and the explicit-selection constraint both matter.

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 correctly takes on the job of stating what is returned, and with only one parameter the burden is light. Missing path conventions and the empty-diff case keep it short of complete.

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

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

Schema coverage is 0%, so the description carries the burden; it does tell the agent that files must be explicitly selected, but gives no guidance on path form (repo-relative vs absolute) or the 80-item cap, leaving the single parameter partially specified.

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?

Names a specific verb (Read) and a specific resource (Git status plus unstaged and staged changes) scoped to explicitly selected source files, which clearly separates it from read_source_file and list_source_files. No sibling is named, so the differentiation is implicit rather than explicit.

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

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

Usage is only implied: the reader infers this is for inspecting pending changes in files the caller already knows about, versus list_source_files for discovery or read_source_file for content. There is no statement of when not to use it and no named alternative.

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

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

Annotations already declare readOnlyHint=true, and 'No system changes' merely restates that guarantee. It adds no further behavioral context such as whether ADB must be running, failure modes, or how quickly state is refreshed.

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 terse sentences with the verb and scope front-loaded and the safety constraint in the trailing position. No wasted text.

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

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

With no output schema, the description usefully enumerates the dimensions returned (Android/ABI/build plus ADB status). Only the lack of any note on output shape or ADB prerequisites keeps it short of full completeness.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool 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?

Uses a specific verb (Read) with a concrete set of resources: Genio Android/ABI/build state and ADB status. It is distinguishable from the camera- and source-file-oriented siblings, though the niche term 'Genio' is left unexplained.

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 read-only framing implies the tool is used to inspect target/environment state before other operations, but no explicit when-to-use, prerequisites, or alternatives among the siblings are named.

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 safety profile is covered. The description adds a real precondition — no board or Trail needed — and implies an authorization filter via 'allowed', but says nothing about result size, truncation, or pagination despite a limit capped at 1000.

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 terse sentences with no filler, and the primary purpose is front-loaded before the precondition. Sized well for a simple listing tool, though it could have spent one of its words on the limit behavior.

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 read-only, zero-required-parameter tool with no output schema, the description covers purpose and preconditions adequately. It is incomplete on result volume/pagination semantics, which matter given the silent 1000-item cap.

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 0% and the single 'limit' parameter (default 300, max 1000) is not mentioned at all in the description. With no compensating text about result caps or how limit interacts with the listing, the description leaves the one parameter undocumented.

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 ('List allowed source files') and scopes it to 'the configured workspace', which cleanly separates it from read_source_file and edit_source_file siblings. It does not explicitly name a sibling to route against, but the purpose is unambiguous.

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

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

'Does not require a board or Trail' implies a usage context (usable without the board/Trail prerequisites other tools need), which is helpful implied guidance. However, it never states when to prefer this over read_source_file or where the 'allowed' filtering comes from, so usage is only partially guided.

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, and the description is consistent with that. It adds real behavioral context beyond the annotation: only 'allowed' files can be read (implying an access whitelist and possible failure for disallowed paths), UTF-8 encoding constraint, and the return of a SHA256 hash for conflict checking.

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

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

A single front-loaded sentence with zero filler; the SHA256 clause earns its place by explaining why the hash is returned. Nothing could be removed without losing information.

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

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

For a one-parameter read tool with no output schema and minimal annotations, the description covers the gist but leaves the path semantics and the failure mode for disallowed files unspecified. Adequate but with clear gaps an agent would hit in practice.

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 0% and the single 'path' parameter is undocumented in the schema, so the description carries the burden. It only hints that the path must point to an 'allowed' file; it does not say whether the path is relative or absolute, what the allowed roots are, or how invalid paths behave.

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 (Read) and resource (one allowed UTF-8 source file), which an agent can distinguish from the sibling list_source_files (plural) and edit_source_file (write). It does not explicitly name those siblings, but the singular/read framing makes the distinction inferable.

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?

There is no explicit when-to-use or when-not statement, but 'including its SHA256 for conflict checking' implicitly signals the read-before-edit/commit workflow involving edit_source_file and commit_candidate. Usage is implied rather than spelled out.

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

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

With no annotations, the description carries the full burden and discloses important side effects: installing an APK, temporarily closing the built-in camera app, waking the board, granting CAMERA permission, returning a job ID, and saving files per run. It still does not cover job polling behavior or any permission prerequisites beyond the temporary grant.

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

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

Two sentences, front-loaded with the action and followed by behavioral details. There is no filler, and every clause provides useful context.

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

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

For a tool with no annotations and no output schema, the description covers the main behavioral effects and return value (job ID, per-run file saving). The notable gap is parameter guidance, especially camera_id and suite defaults, but the core invocation context is present.

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 0%, so the description must compensate for parameter meaning. It references capture/control validation, which loosely maps to the suite enum, but it never explains camera_id or the defaults, leaving most parameter semantics undocumented.

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

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

The description states a specific verb and resource: install the built diagnostic APK and start YUV capture/control validation. It clearly scopes the operation to diagnostic camera validation and mentions the job ID return, making it distinguishable from build/probe siblings.

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?

Usage is implied by 'built diagnostic APK' and 'validation,' suggesting it should be called after building. However, it does not explicitly say when to use this versus build_camera_probe, get_camera_capabilities, or other siblings, nor does it state exclusions.

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