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

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the agent at least knows this is a local, non-destructive-but-not-read-only operation. The description only restates the write side effect ('create evidence job') and adds nothing about runtime cost, whether the job is asynchronous, permissions/toolchain prerequisites (cf. install_tools, doctor), or how results are later retrieved (list_artifacts, read_artifact, summarize_job).

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?

It is a single short sentence with no padding, which is good, but the compression comes at the cost of clarity — the two clauses are cryptic rather than front-loaded with actionable 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 tool that spawns a background job with no output schema, the description omits critical context: that the call returns a job rather than findings, and which sibling tools consume that job. Given 0% parameter coverage and thin annotations, the one-line description is not sufficient for correct invocation.

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

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

Schema description coverage is 0%, so the description carries the full burden and fails: neither the required 'path' (presumably the APK) nor the 'mode' enum (both/code/resources) is explained or mapped to what the engines do. The word 'engines' hints at the code/resources split but does not disambiguate the values.

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 gives a verb phrase ('Run static engines') and a side effect ('create evidence job'), which is more than a restatement of the name. But 'static engines' and 'evidence job' are unexplained jargon, and it never distinguishes this from sibling tools like inspect_apk, review_manifest, or compare_apks, which an agent could easily confuse with it.

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 when-to-use or when-not-to-use guidance and no mention of the obvious alternatives. An agent cannot tell from the description whether to reach for analyze_apk versus inspect_apk for a given task.

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, closed-world, non-destructive, so safety is covered; the description adds only that the output is "static" (fixed, not computed against live state) and that it includes "limitations," which is mildly useful context. It does not say whether the output is a list, a map of feature flags, or prose, nor whether anything is cached or versioned.

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?

It is short but not concise in the useful sense: a four-word fragment with no subject, verb, or structure, which is under-specification rather than economy. Not a single word is wasted, but the space that was saved is exactly the information the agent needed.

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 the full burden of explaining what is returned, and it does so only in the vaguest terms. For an introspection tool whose entire value is its return payload, this leaves the agent unable to predict the response shape or know what "limitations" covers.

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 and the baseline of 4 applies. It correctly implies a no-argument call by describing the result rather than any inputs.

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?

"Static capabilities and honest limitations" is a noun fragment that largely restates the tool name and never states a verb or what an agent gets back. It does not distinguish this tool from siblings such as doctor, install_tools, or list_artifacts, so an agent cannot tell from the description alone that this is a self-description/introspection endpoint.

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 guidance on when to call this versus doctor (the closest sibling) or when not to call it, and no indication of preconditions or expected timing. The fragment offers nothing an agent could use to choose between this and the other introspection-style 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 already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds one real behavioral fact beyond that: the comparison is over CRC32/size inventories rather than raw bytes or metadata. It does not say how unmatched entries or added/removed files are reported, but with annotations carrying the safety burden a 3 is fair.

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?

It is short and has no wasted words, but it is a bare noun-phrase fragment rather than a sentence, and the terseness is under-specification rather than efficiency. There is no front-loaded statement of inputs or outcome to anchor the agent.

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

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

With three parameters at zero schema coverage, no output schema, and no explanation of how two inputs are supplied or what the diff contains, the definition leaves an agent guessing on nearly every call detail. The only thing keeping it above 1 is that the annotations cover safety and the description conveys the comparison granularity.

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 define 'before', 'after' and 'limit' — and it defines none of them. An agent cannot tell whether before/after are file paths, artifact IDs, or build labels, nor what the limit of 100 caps (changed entries? diffs?). This is a three-parameter tool with completely unexplained inputs.

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 verb 'Compare' plus the resource 'APK identities and CRC32/size inventories' tells an agent this diffs two APK artifacts at the file-inventory level. That is a specific verb+resource pairing, though the phrase 'APK identities' is vague and nothing distinguishes it from the sibling tools inspect_apk or analyze_apk.

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 when-to-use guidance at all. The description never says whether this is for regression checks between builds, never states prerequisites (do the inputs need to be extracted artifacts?), and does not point an agent to inspect_apk or analyze_apk when it actually wants a single-APK view.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that it checks Java and installed tool integrity, but it does not explain what a failed check looks like or how results are reported.

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 efficient phrase with the action and scope front-loaded. It avoids unnecessary wording, though it is terse enough that some useful diagnostic context is absent.

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 no-parameter diagnostic tool, the description identifies what is checked and annotations cover safety. However, with no output schema, it does not explain what the check returns or how an agent should interpret success versus failure.

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 burden on the description. The baseline for a no-parameter 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?

States a specific verb, "Check," and specific resources: local Java and installed tool integrity. It is clear what the tool does, but it does not explicitly distinguish itself from siblings such as capabilities or install_tools.

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

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

Usage is implied as a diagnostic or health-check step, likely before or after installing tools, but the description gives no explicit when-to-use guidance, prerequisites, or alternatives to consider.

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

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

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the word 'bounded', which implies a size or depth limit but never says what is bounded, what gets truncated, or what form the inventory takes, leaving the main behavioral question unanswered.

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?

It is short, but that is not the same as concise: 'Bounded APK inventory, not signature verification' is a noun fragment with no subject or verb, and 'bounded' is unexplained filler. The brevity comes from omitted information, not from efficient wording.

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 an inspection tool with no output schema and a 0%-documented parameter, the description should say what the inventory contains and how the path is interpreted. Instead it leaves an agent unable to predict the response shape or the input format.

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 'path' has 0% schema description coverage, so the description carries the full burden, and it says nothing about the parameter. It never states whether path is a local file path, a remote URL, or one of the listed artifacts.

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 fragment 'APK inventory' identifies the resource and a rough intent, but the verb is missing and 'bounded' is never explained. It distinguishes itself from signature verification, but that is not one of the named siblings, and it never contrasts with analyze_apk or review_manifest, which look like the closest alternatives.

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 only selection guidance is a negative: 'not signature verification'. There is no statement of when to prefer this over analyze_apk or review_manifest, and no prerequisites or exclusions an agent could act on.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only that the target formats are DEX and ELF and that nothing is executed — the latter largely restates readOnlyHint. It says nothing about how the file is read, error behavior on malformed binaries, or output volume.

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 short, front-loaded clause with no filler or repetition. It is terse to the point of being a fragment, but every word carries 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?

With no output schema and no parameter documentation, the description must carry more weight than it does. It omits what the returned header data looks like and what 'limit' controls, which an agent needs in order to invoke the tool correctly.

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

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

Schema description coverage is 0% for two parameters. The description implies 'path' points at a DEX/ELF file but never states it, and the 'limit' parameter (1-200, default 100) is completely unexplained — the agent cannot tell whether it caps header entries, lines, or bytes.

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 ('Inspect') and a specific resource ('conventional DEX and ELF headers'), so the agent knows exactly what class of artifact is read. It does not explicitly differentiate itself from siblings like inspect_apk or analyze_apk, which also operate on binary 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?

There is no when-to-use guidance and no named alternative. The phrase 'without execution' implies a static, safe inspection, but the description never says when to choose this over inspect_apk or review_manifest, 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=false and openWorldHint=true, so the agent knows this mutates state and reaches the network; the description's 'download' corroborates but adds nothing beyond that. It does not say where files land, whether existing installs are overwritten, how long a download takes, or how 'dual operator consent' is actually enforced — the one distinctive claim is left opaque.

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?

It is short with no filler, but it is an under-specified fragment rather than a front-loaded sentence. Length is not the problem; the missing content is.

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 non-read-only, open-world tool with a required consent flag and no output schema, the definition should say what gets installed, from where, and what the confirmation gates. None of that is present, so an agent cannot confidently decide whether or how to call 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?

The single required boolean confirm_downloads has 0% schema description coverage, so the description must carry it — but it never mentions the parameter or explains whether setting it to true constitutes the 'dual operator consent' or merely part of it. That ambiguity matters for a state-changing tool.

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 phrase 'Download official engines only with dual operator consent' is a fragment that names an action (download) but not the resource clearly — 'engines' is undefined, and the tool name (install_tools) implies installation, not just download. It gives no hint of what distinguishes this from siblings like capabilities, doctor, or list_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?

There is no explicit when-to-use or when-not-to-use guidance and no named alternative. 'Only with dual operator consent' gestures at a precondition but never explains what qualifies, who the two operators are, or what to do if consent is absent.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered elsewhere. Beyond that, the description contributes essentially nothing — it does not explain ordering of results, whether paging is stable, what happens when offset exceeds the collection, or the shape of returned items.

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?

At four words there is no wasted filler, but this is under-specification rather than conciseness — the fragment lacks a subject and verb and omits information an agent needs. A single well-formed sentence would be both shorter in effort and far more informative.

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 required parameter, two bound-constrained optional parameters, zero schema descriptions, and no output schema, the description carries the full burden of clarification and simply does not deliver. An agent could invoke it but could not predict pagination behavior or how to iterate through results.

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 all three parameters (job_id, limit, offset) are undocumented in the schema, and the description does not compensate. The word "page" weakly implies limit/offset semantics with a default page size, but nothing is said about the required job_id or the 1-500 bounds on limit.

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?

"Page job file inventory" does signal that this retrieves a paginated collection of files belonging to a job, but the phrasing is terse and never uses the word "artifact" from the tool name, leaving the agent to infer that "job file inventory" equals artifacts. It also does nothing to distinguish this from siblings like read_artifact or search_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?

The description gives no indication of when to choose this over read_artifact (single artifact retrieval) or search_artifacts (filtered lookup), both of which are obvious alternatives. There is no statement of prerequisites, no when-not-to-use condition, and no routing guidance at all.

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 readOnlyHint=true, destructiveHint=false and a closed-world scope, so the safety profile is covered. The description does add two genuinely useful behavioral facts beyond that: the returned content is untrusted (relevant for prompt-injection handling) and output is capped at 16 KiB. It does not say whether truncation is signalled or how to continue reading, which matters for a capped reader.

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?

It is front-loaded with the verb and free of filler, but the telegraphic fragment style omits connecting information that would have cost only a few words, so it reads as under-specification rather than disciplined conciseness.

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 four-parameter reader with no output schema, the definition leaves key gaps: the job_id/path relationship, what happens when the limit is reached, and whether the response indicates more content available. The annotations cover the safety profile, but the description does not do enough for an agent to invoke this confidently on large artifacts.

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% across four parameters, so the description carries real burden. It partly compensates by revealing that offsets are in bytes (not lines or records) and that the read size cap is a KiB budget, which map to offset and limit. It says nothing about job_id or path, nor how the two required parameters combine to identify the artifact.

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 the verb 'Read' and characterises the content as 'untrusted text', which hints at artifact content and separates it loosely from siblings like list_artifacts or search_artifacts. However, it never says it reads the contents of a specific artifact file identified by job_id/path, so the resource is only implied by the tool name rather than the description.

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 when-to-use guidance at all: nothing says to use this when you need the raw contents of a file rather than its metadata, and no mention of the obvious alternatives in the sibling set (list_artifacts, search_artifacts, inspect_apk). The agent must infer routing from the name alone.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds one genuine behavioral signal beyond that: the tool returns supporting evidence rather than a security conclusion, which shapes how an agent should interpret and present results. It says nothing about pagination, truncation, or what happens when the decoded manifest is missing.

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?

It is a single short sentence with no filler, so nothing is wasted, but the brevity comes at the cost of specification rather than being earned by density. The most informative part ("not security verdict") is trailing and easy to skim past.

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, no annotations gap, 0% parameter coverage, and a required job_id that is never defined, the description leaves an agent unable to call the tool confidently. It should at minimum state what job_id identifies, what the path default means, and what form the returned evidence takes.

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% across two parameters, so the description must compensate and does not. "Decoded manifest" loosely hints that path refers to a decoded AndroidManifest.xml (default apktool/AndroidManifest.xml), but job_id — the required parameter — is never explained, nor is the relationship between job_id and path.

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?

"Review decoded manifest" gives a verb and a resource, but "review" is ambiguous about what is actually produced (extracted fields? raw XML? flagged entries?). The clause "not security verdict" does differentiate it from analyze_apk-style siblings, but only by negation, so an agent still cannot fully predict the output.

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 "with evidence, not security verdict" implies a boundary (don't use this for a security assessment), but no sibling is named and no positive condition for choosing this over inspect_apk, analyze_apk, or read_artifact is given. Prerequisites such as needing a previously decoded APK job are 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 readOnlyHint, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds two real pieces beyond that: results are capped ("bounded") and excerpts may leak secrets, which is a meaningful handling caution. It still omits whether matching is case-sensitive, whether results are ranked, and what an excerpt looks like.

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?

Five words, front-loaded, with zero filler — but the brevity is under-specification rather than economy. The secret-exposure warning is valuable and correctly placed, yet the same sentence leaves out the basic subject of the search.

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, 0% schema coverage, and an unannotated job_id, the description should explain that search is scoped to a job, what limit does, and roughly what comes back. None of that is present, leaving an agent to infer the core calling contract.

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 carries the full burden and largely drops it. "Bounded" gestures at limit but gives no value or meaning; job_id is never mentioned, so its scoping role is undocumented; and query is only implied to be a literal string. Two required parameters are effectively unexplained.

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?

"Bounded literal text search" gives a verb and a search mode (literal, not regex), which is genuinely useful. But the description never says what is searched — the artifact corpus is only inferable from the tool name — and it does not distinguish itself from read_artifact or list_artifacts, which are the obvious 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?

There is no when-to-use or when-not-to-use guidance and no named alternative. An agent must guess whether to scan with search_artifacts or fetch a known artifact with read_artifact, and nothing here routes that decision.

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 indicate this is not read-only, not destructive, and closed-world, which is consistent with "Write Markdown summary." The description adds useful scope by saying the summary covers engine evidence rather than original source. However, it does not disclose where the summary is written, whether existing summaries are overwritten, or what permissions or job state are required.

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 front-loaded sentence with no filler, and the action is easy to identify. It is very terse, but conciseness itself is strong.

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 write-style tool with no output schema and an undocumented required parameter, the description is too thin. It does not explain where the Markdown summary goes, how it can be retrieved, or what job_id must identify, leaving important operational details 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?

The schema has 0% description coverage and the description never mentions job_id. The parameter is only weakly inferable from the tool name, and the description does not explain what a job ID represents or how to obtain one.

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 action and output: write a Markdown summary of engine evidence. It also clarifies a meaningful scope boundary by saying this is not the original source. It does not explicitly differentiate itself from siblings, but the purpose is understandable.

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 guidance on when to use this tool versus alternatives such as read_artifact or analyze_apk. The phrase "not original source" hints at a content boundary, but it does not tell the agent which situations call for summarize_job or what prerequisites are required.

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