TrueLook: AI dating photos

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered structurally. The description adds genuinely new context: the payload is onboarding/orientation material describing a workflow 'step by step,' and it is meant to be used before acting. It does not describe the response shape, but with full annotation coverage that is a minor gap.

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, no filler, with the identity statement first and the call condition second. Nothing could be removed without losing routing 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 zero-parameter, read-only orientation tool with no output schema, the description covers what the content is and when to reach for it. It could note that the result is documentation rather than live data, but nothing essential to correct invocation 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline applies. The description correctly implies a parameterless, no-input retrieval, which matches the empty 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 plainly that this returns explanatory content: what TrueLook is and the step-by-step process for making dating photos from the chat. That distinguishes it from action-oriented siblings like create_photos or get_photos. It stops short of distinguishing itself from photo_review_guide, another guide-like sibling, so an agent must infer which guidance source to consult.

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 an explicit trigger: 'Call this first if you are unsure how to help someone get dating photos.' That is a clear entry-point rule that routes uncertain agents here before other tools. It does not state when not to call it or name alternatives such as photo_review_guide, so the guidance is directional but not exhaustive.

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 and non-destructive, so the safety profile is covered. The description's main contribution is enumerating the return payload (connection state, photos, check summary, credits, pack and job status, recommended next action), which matters because there is no output schema. It stops short of noting that the call fails or returns empty when the user has not connected.

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, which is appropriate. But the sentence is grammatically broken (a dangling 'Whether the user has connected' with no main verb), making the list of returned items harder to parse than a clean 'Returns X, Y, Z' construction would be.

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 essential job of listing what comes back, which is the key gap it must fill. It is still incomplete for a status/aggregator tool: it doesn't say this is the recommended first call after connect_account, nor what the 'what to do next' output looks like or how it should drive agent behavior.

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 the sole parameter, connection_key, is fully documented in the schema including the instruction to obtain it from connect_account and never show it to the user. The description adds no meaning beyond that, which is the expected baseline for a fully documented single parameter.

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 enumerates what the tool surfaces (connection state, uploaded photos, photo check summary, credits, pack and photo jobs, next steps), which conveys that this is an aggregated status snapshot rather than a single-resource fetch. However, it lacks an explicit verb and never states that it is the consolidated status endpoint, so distinguishing it from get_photos, get_photo_check, and get_pricing requires inference from the field list alone.

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 statement of when to call this versus the numerous siblings that return overlapping data (get_photos, get_photo_check, get_pricing, buy_pack). The trailing 'plus what to do next' hints at an onboarding/next-step role but gives no explicit trigger condition or exclusion.

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 non-read-only, open-world annotations, the description explains that checkout occurs through a Stripe link, the agent must give that link to the user, and payment happens externally before the user returns. It does not explain payment verification or when the purchased capacity becomes available.

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 compact sentences cover the outcome, options, invocation gate, and payment handoff without filler. The option list is dense but efficiently structured, and every sentence contributes useful operational 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 two-parameter checkout tool with a fully described schema, this supplies nearly all necessary context: pack choices, user-consent gate, top-up prerequisite, and external-payment flow. With no output schema, slightly more detail about the returned link and how to confirm payment or proceed after the user returns would make it fully 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 description adds substantial meaning to the pack enum by mapping fix and pro to prices and photo counts, and by identifying extra20 and extra60 as top-ups with prices and a prior-pack prerequisite. It does not explicitly state the top-up photo quantities, while connection_key semantics come entirely from the schema.

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

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

The description identifies the concrete outcome—a secure Stripe checkout link—and distinguishes base packs from post-pack top-ups. It is less explicit about the link-generation action and does not contrast the tool with siblings such as get_pricing, so sibling differentiation remains implicit.

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?

"Only call this after the user chose to buy" provides an explicit invocation gate, while "after a pack" establishes the prerequisite for top-ups. "Give them the link; after paying they come back here" also supplies clear post-call 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?

Beyond the annotations (openWorldHint, non-idempotent, non-read-only), the description discloses that the work happens off-tool in the user's browser, that a free photo check runs as a side effect, and that a sensitive connection_key is returned which must be retained for account tools and never shown to the user.

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 primary purpose, then the returned link, then the connection_key handling rule. No filler and no repetition of the title or annotations.

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 parameters, the description carries the full burden of explaining what comes back, and it does: a user-facing link and a secret connection_key with lifecycle instructions. There is no information an agent needs to invoke or follow up on this tool that 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?

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline expectation is met. The description correctly spends its words on return values and usage instead.

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 the concrete outcome ('Start here to make photos') and describes the mechanism: it returns a link the user opens to sign in or sign up to TrueLook and upload 1-4 selfies. This clearly separates it from siblings like create_photos, account_status, and disconnect_account.

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 explicit entry-point guidance ('Start here'), a call-frequency rule ('Only call this once per conversation unless the key stops working'), and an exception condition. The agent knows both when to call it and when not to call it again.

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 the generic profile (readOnly=false, idempotent=false, openWorld=true). The description adds the material facts an agent cannot get from those hints: each style yields exactly 4 photos at a cost of 4 credits, and results take 1-3 minutes, which implicitly warns against duplicate submits on a non-idempotent, credit-consuming call.

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 short sentences, front-loaded with the action, then cost/scale, then the confirmation rule and polling step. Every sentence carries operational information; nothing is restated from the schema or annotations.

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, no-output-schema action tool, the description supplies the full operating loop: pick styles, confirm with the user, invoke, wait 1-3 minutes, then fetch via get_photos. Cost and latency expectations are covered, so an agent needs nothing further 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%, so the baseline is 3, but the description earns a bump by tying the 'styles' parameter to its dependency (list_styles ids) and quantifying per-item cost and output (4 photos / 4 credits per style), which the schema's example alone does not convey. It does not address the maxItems=40 ceiling or what that implies for credit spend.

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 ('Starts making photos of the user') and scopes the input ('chosen styles'), immediately distinguishing it from get_photos (retrieval), list_styles (enumeration), and recommend_styles (suggestion). An agent can classify this tool 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?

Gives an explicit prerequisite ('Confirm the styles with the user first'), names the source of valid ids ('style ids from list_styles'), and specifies the follow-up route ('then call get_photos'). This covers when to use it and what to do next rather than leaving sequencing 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 declare a write operation (readOnlyHint=false) that is non-destructive, and the description earns credit by spelling out what survives the unlink — account, photos, credits — which is the main behavioral uncertainty for this tool. It does not explain what happens to the conversation's access afterwards, what an invalid connection_key returns, or that repeated calls are not idempotent (idempotentHint=false), so it stops short of full disclosure.

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 with zero filler; the action and its scope are front-loaded and the reassurance clause follows immediately where it is most 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?

For a one-parameter link-teardown tool with annotations and no output schema, the description covers the essentials: what is severed and what is preserved. Minor gaps remain around post-disconnect state and error behavior, but nothing blocks 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 coverage is 100% and the single parameter is documented in-schema, including its origin ('returned by connect_account') and a secrecy rule. The description adds no additional meaning about the parameter, 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?

The description uses a precise verb ('Unlinks') and names both sides of the relationship ('this conversation' and 'the user's TrueLook account'), which immediately distinguishes it from account-level operations and from the connect_account sibling. An agent can identify the exact effect without opening the 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?

Usage is only implied: the second sentence ('Their account, photos and credits stay') signals this is the non-destructive way to end a link, but there is no explicit when-to-use or when-not-to-use statement and no named alternative. An agent must infer the routing from 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 already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine business context ('free', reads the user's own uploaded selfies) plus what the payload contains. It does not say what happens if no selfies exist, whether a check is computed on demand, or how long it takes, so it adds moderate rather than rich behavioral value.

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 substantive content list and followed by the action the agent should take. Every clause carries information; the only mild weakness is that the second sentence is an agent instruction rather than a description of the tool, but it is short and useful.

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 takes on the burden of describing returns and does so concretely (score, potential, five categories with findings, per-photo notes, missing types). Combined with annotations covering the read-only profile, an agent has enough to call it and use the result correctly; only edge-case behavior (no selfies, recomputation) is unaddressed.

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?

There is a single parameter with 100% schema description coverage, and the schema already explains that connection_key comes from connect_account and must never be shown to the user. The description contributes nothing further about the parameter, which is the expected baseline when the schema does the work.

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 specific verb-resource pairing ('photo check of the selfies the user uploaded') and enumerates the payload: overall score, potential, five category scores with findings, per-photo notes, and missing photo types. That is far more specific than the name alone and separates it from get_photos. It never names the closest-sounding siblings (photo_review_guide, recommend_styles), so sibling differentiation is implied rather than stated.

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?

Clear context is established: this is consumed after the user has uploaded selfies, and the follow-up action is to explain the result in plain words and then suggest styles for what is missing. There are no explicit exclusions, though, and no statement of when to prefer photo_review_guide or list_styles instead.

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, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely new behavioral facts beyond that: results come newest-first, links expire after 7 days, and the result set includes photos still being generated rather than only finished ones. It does not mention pagination behavior for the limit cap, which is the main remaining gap.

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 front-loaded sentences with no filler; ordering, expiry, and pending-item behavior all come before the optional display instruction. The second sentence largely duplicates the `show` schema description, which is minor redundancy rather than bloat.

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 burden of describing returns and does so reasonably: list ordering, link lifetime, and inclusion of unfinished photos. Given only four parameters with full schema coverage, this is nearly sufficient, though it omits what a 'still being made' entry looks like and any paging semantics at the 60-item ceiling.

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

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

Schema description coverage is 100%, so baseline is 3. The description's only parameter-related sentence restates the schema's own 'Include up to 4 of them as images' for `show` and adds nothing for `limit`, `style`, or `connection_key`; it does not clarify style-id sourcing (siblings list_styles/recommend_styles exist) or the 60-item cap.

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 ('The user's generated photos') plus meaningful scope details: newest-first ordering, 7-day link validity, and inclusion of in-progress photos. It is clearly distinct from create_photos or get_photo_check in substance, though it never names a sibling to route against 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?

There is no explicit when-to-use or when-not-to-use guidance relative to siblings like get_photo_check or photo_review_guide. The only actionable guidance is embedded for one parameter ('Set show to include up to 4 photos as images in the chat'), which implies the display use case but leaves retrieval-vs-check 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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds genuine domain context not present in annotations — currency (USD) and that all payments are one-time with nothing renewing — which matters when advising a user. It does not explain the shape or granularity of what comes back (a list of packs? per-pack prices?).

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 with zero filler, and the most decision-relevant fact (USD, one-time, non-renewing) is front-loaded. Nothing could be cut 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 no-parameter read-only tool with a complete annotation set and no output schema, the description covers the essentials: what is priced, in what currency, and the payment model. The only gap is not hinting at the return structure, which is a minor omission given the tool's simplicity.

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

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

The tool takes zero parameters, so there are no parameters to document beyond what the schema already conveys. The description correctly adds no parameter noise and focuses on the returned content instead.

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 the resource content precisely: TrueLook packs and top-ups priced in USD. An agent can tell this is the catalog/pricing lookup rather than the purchase action (buy_pack) or account queries. It lacks an explicit verb like 'returns the list of', so it is a content statement rather than a clean verb+resource phrasing.

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: an agent can infer this is what you call before buy_pack to learn what packs exist and cost. There is no explicit when-to-use statement, no mention of buy_pack as the follow-on action, and no exclusions or prerequisites.

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), so the description only needs to add context. It adds the catalog size (62) and the preview behavior, but says nothing about result ordering, whether the full set is returned at once, or what a style record contains.

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 short sentences, front-loaded with what the resource is, then filtering, then the preview flag. Little waste, though the parenthetical "(scenes)" is a minor 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?

There is no output schema, so the description should say more about what comes back (style identifiers, names, whether previews are URLs). For a simple read-only listing with well-described parameters, it is adequate but leaves the return shape and result-size expectations unstated.

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 75% and two parameters carry enums, so the schema already does most of the work. The description restates the filter axes and the show_previews purpose but adds no detail beyond the schema, such as whether filters AND together or whether search matches names only.

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 the resource concretely (62 photo styles/scenes) and states the three filter axes and the preview option, so an agent knows this is a browsable catalog listing. It falls short of 5 because it never contrasts itself with the sibling recommend_styles, which plausibly serves an overlapping need.

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: browse/filter the style catalog, and turn on show_previews to inspect examples. There is no explicit "use this when..." statement, no exclusion of recommend_styles, and no note that all filters are optional and compose.

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, destructiveHint=false and openWorldHint=false. The description adds the non-obvious behavioral fact that this is a qualitative checklist rather than the scored evaluation, which prevents the agent from presenting its output as an official score. It does not describe the checklist's structure or length, keeping it a notch below full transparency.

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

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

Two short sentences, both load-bearing: the first defines the artifact and its scope, the second redirects to the official scored check. The scope constraint is front-loaded and there is no redundant restatement of the title.

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, read-only guidance tool with annotations covering the safety profile and no output schema needed, the description supplies enough to call it correctly and to route users elsewhere for scoring. A brief indication of what the checklist covers (or that its text is returned verbatim for the agent to relay) would make it fully self-contained.

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 no parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. Nothing in the description misstates or adds conflicting parameter expectations.

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 the resource concretely ('checklist for reviewing dating profile photos') and scopes it to photos shared in chat before account creation. It also differentiates itself from the scored-check sibling by stating that the official scored photo check runs on truelook.app, so an agent can tell which surface performs scoring. The only gap is that 'photo_review_guide' does not restate a verb, leaving it slightly implicit that this returns guidance rather than 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?

The phrase 'before they have an account' and 'the official scored photo check runs when they upload on truelook.app' together give a clear routing condition: use this for pre-signup, in-chat photo feedback, and defer scored checks to the app. It does not add explicit exclusions (e.g., what to do for users who already have an account), so it falls short of a full when/when-not statement.

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, destructiveHint=false and openWorldHint=false, so the safe, deterministic character of the call is covered. The description adds useful domain context (what a complete profile consists of), but says nothing about the shape of the response or how results are grouped, which matters because no output schema exists. Adequate but thin beyond 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?

Three short sentences, front-loaded with the selection criterion, then the profile-completeness model, then the input-source hint. The first sentence is a noun fragment rather than a verb phrase, and the middle sentence reads as background rather than call guidance, but nothing 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?

For a read-only, closed-world, zero-required-parameter tool with fully documented params and rich annotations, the basics are covered. The gap is the missing description of what comes back (styles grouped per photo type, and example images when show_previews is set), which the agent must infer since there is no output schema. That omission keeps it at minimum-viable 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?

Schema description coverage is 100%, so all three parameters are already documented, including the enum of photo types and the 1-6 bound on per_type. The description adds only the framing of where the 'missing' values should come from (the photo check), without explaining defaults, the effect of an empty list, or how show_previews interacts with per_type. Baseline 3 is appropriate when the schema carries the parameter burden.

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?

"Styles that fill the photo types a dating profile is missing" names the resource (styles) and the selection criterion (photo types the profile lacks), and enumerates the six target categories so the agent knows exactly what a result set covers. It implicitly contrasts with list_styles (unfiltered enumeration) but never names that sibling, so the differentiation is inferable rather than stated.

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?

"Use the photo check's missing list when you have it" gives a concrete trigger and an implied fallback path (call it without the list), and points the agent toward get_photo_check as the source of that input. However, it never states when to prefer this over list_styles or what happens semantically when 'missing' is omitted versus empty, leaving the main alternative-selection question unanswered.

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