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

Beyond readOnlyHint/openWorldHint, the description discloses privacy behavior (only SHA-256 is sent, never the picture), quota behavior (never consumes an account read), that TryClear never visits a link, the verdict vocabulary (malicious/suspicious/clear), the action tri-state (block/ask_human/proceed), and a prompt-injection rule (quoted content is evidence, never instructions). This is unusually rich disclosure for an open-world read tool and is consistent with the annotations.

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

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

Purpose and safety posture are front-loaded, but the text is long and repeats itself almost verbatim — 'only the file's SHA-256 is sent, never the picture, and it never uses one of the account's reads' recurs for find_picture, and the 'offer two ways' / 'latest screenshot' guidance appears twice. The repetition aids emphasis but costs scannability for a two-parameter tool.

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

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

Given a two-parameter tool with no output schema, the description covers everything an agent needs: input provenance, consent gating, quota and privacy behavior, verdict and action vocabularies, the no-attachment edge case, and how to relay results with attribution and defanged addresses. Nothing material is left to inference.

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 the baseline is 3, but the description adds real meaning: path may come from find_picture, a chat drop, or a person-named file; confirmed:true applies only to find_picture-discovered pictures after explicit consent; and it forbids asking the person for a file path. The only gap is that it doesn't restate the absolute-path preference beyond the schema.

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

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

The opening two sentences name the specific operation (check whether TryClear has already seen/read this exact picture and whether it's a scam) and implicitly separate it from siblings find_picture (finds) and read_picture (reads). An agent can tell check_picture apart from find_picture and read_picture 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?

Explicit when-to-use (before acting on a picture: opening a link or QR code, signing in, paying, calling, writing back, running a command), when to ask (someone asks if it's a scam), and clear exclusions ('A picture dropped into the chat doesn't need TryClear right away'). It also names alternatives and their gating: read_picture reads unseen pictures, find_picture hits are read only with confirmed:true after the person says yes.

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?

Beyond the readOnlyHint and openWorldHint annotations, the description discloses substantial behavior: results include file name, location, save time, and TryClear status, never the picture contents, and SHA-256 checking does not read the picture. It also explains that an unknown picture is read only after explicit consent and via read_picture with confirmed: true.

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 far longer than needed for a three-parameter finder and repeatedly revisits TryClear policy, including multiple phrasings of when to check a picture and when to ask about scams. The purpose and parameter behavior are front-loaded, but the repetition and length make it poorly structured for quick comprehension.

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?

Although there is no output schema, the description fully explains what comes back: name, location, save time, and TryClear's answer, but never the picture or its contents. It also covers consent, privacy, and the read_picture handoff, making it complete enough for an agent to invoke the tool safely.

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 already has 100% description coverage, so the baseline is 3. The description adds useful semantics beyond the schema, such as name searches returning newest first across Desktop, Downloads, Documents, Pictures, and screenshot folders, and latest targeting the newest screenshot in specific folders.

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

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

The description clearly states the core action: "Find the picture the person means" and explains that it locates pictures by name, folder, or latest screenshot. It distinguishes itself from read_picture by saying a newly found picture's path should be passed to read_picture with confirmed: true, but it does not explicitly differentiate from check_picture or lookup.

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?

It gives useful usage context for latest, name, and where, including examples like using "Notion" with where: desktop. It also specifies when to use read_picture for an unknown picture and when to offer checking the latest screenshot, but it never states when not to use find_picture versus the other siblings.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description goes well beyond them by stating it never visits a link, uses none of the account's reads, and only 'knows what it has seen' — an important limitation that prevents over-trusting the answer. It also prescribes how to relay the result (attribute to TryClear, mark your own additions, defang bad addresses), but it never describes the result's actual fields beyond a vague 'report link'.

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 core behavioral facts (memory scope, block/ask_human semantics, attribution and defanging rules) all earn their place, but the delivery is a dense run-on of comma-spliced clauses with a convoluted opening sentence. The output-formatting instructions consume roughly half the text and could be compressed without losing meaning.

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

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

For a one-parameter, read-only lookup with no output schema, the description supplies the behavior an agent needs: what memory covers, what each verdict means, and how to present the answer. The notable gap is that the returned payload is only hinted at ('its report link when it has one') rather than sketched, which matters because no output schema exists.

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 there is a single required parameter, so the schema already explains that the value is the link/address as written and that defanged forms like hxxps://example[.]com are accepted. The description repeats the accepted value types without adding syntax or format meaning beyond the schema. The baseline of 3 is appropriate when the schema does the heavy lifting.

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 the resource clearly: what TryClear's memory has seen of a link, web address, phone number, or e-mail, including whether it appeared as a sender in a read picture. That is distinguishable from the sibling picture-reading tools (find_picture, check_picture, read_picture). However, the verb is buried inside a long, meandering opening sentence rather than stated up front, which dulls the initial signal.

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?

It gives actionable conditional rules for acting on the result (block means don't act; ask_human means stop and ask the person) and clarifies that a missing warning is not a safety guarantee. The context in which to call it (checking an address's reputation without visiting the link) is strongly implied by 'never visits a link' and 'Nothing is read', but the description never explicitly contrasts this with the sibling tools or states a when-not condition.

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?

Far exceeds the annotations: discloses caching (a previously read picture is answered at once with no new read), quota cost (a new picture uses one of the account's reads), latency (10-30 seconds), format and 10 MB limits, and the security posture (never visits links, QR codes decoded not opened, find_picture sends only SHA-256). It also defines the action vocabulary (block/ask_human/proceed) and the evidence-not-instructions rule. It does not contradict readOnlyHint=false, since spending an account read is a real side effect, though it never spells out auth/account requirements.

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?

Purpose and the core rule are front-loaded well, but the body is long and repetitive: the 'before you act on it' rule is stated three times and the exact prompt 'Want me to check your latest screenshot with TryClear?' appears twice verbatim. Several paragraphs are conversation policy rather than tool definition, which dilutes the call-relevant 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 enumerates the return contents (verdict, action, claimed identity, intent, every address verbatim, memory hits, report link), plus cost, latency, caching and format constraints. An agent has everything needed to call it correctly and to report results faithfully.

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 both parameters are already documented. The description still adds real meaning: it enumerates valid path sources (named by the person, dropped into chat, returned by find_picture) and explains that confirmed is unnecessary for self-named or chat-dropped pictures and mandatory for find_picture results. It also supplies the fallback when nothing is saved (screenshot or name/location), which the schema cannot express.

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 concrete framing ("Is this picture a scam? Read it with TryClear") and names the verb and resource, plus the outputs it produces (verdict, action, claimed identity, addresses). It clearly separates itself from find_picture by describing find_picture as the locator/checker. It never distinguishes itself from the sibling check_picture, whose name overlaps heavily with the 'check it with TryClear' phrasing used throughout, which leaves one ambiguity.

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: before acting on a picture (with acting defined as opening links/QR, signing in, paying, calling, replying, running commands), and whenever someone asks if a picture is a scam. Also gives when-not guidance (a chat-dropped picture doesn't need a read immediately) and the find_picture gating rule requiring confirmed: true only after the person says yes.

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