DatingProfile: AI dating photos

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

Annotations already declare this is a safe, idempotent, non-destructive read with no external side effects, so the description carries less burden. It adds that the content is procedural orientation rather than user data, but says nothing about what the answer actually returns or whether it reflects live account state.

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, no filler, with the what-is-it framing first and the call condition second. Every clause earns its place.

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

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

For a zero-parameter, read-only orientation tool with no output schema, the definition covers purpose and invocation timing adequately. The only real gap is not indicating whether the guidance is static documentation or account-specific.

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 are zero parameters, so there is nothing for the description to disambiguate and the baseline applies. It correctly implies no input is needed to get the explanation.

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 what the tool offers: an explanation of what DatingProfile is plus a step-by-step of how photos get made from this chat. That clearly distinguishes it from action siblings like create_photos or get_photos, though 'what DatingProfile is' is the vaguer half of the sentence.

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?

'Call this first if you are unsure how to help someone get dating photos' gives a concrete trigger condition tied to agent uncertainty. It stops short of naming alternative tools to consult when the agent is already confident, but the selection condition is clear.

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, it discloses that the user must open a link, sign in or sign up, upload a selfie, and that the call also runs the free photo check. It also explains that the returned connection_key must be kept for every account tool and never shown to the user, which is important behavioral context.

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 front-loaded with 'Start here to make photos' and then adds only necessary details about the link, sign-in flow, selfie upload, photo check, and connection_key handling. Every sentence contributes useful information without redundancy.

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

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

Given the tool's complexity, lack of an output schema, and open-world behavior, the description covers the key return values, required user action, secret handling, and call frequency. An agent has enough context to invoke it correctly and guide the user.

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

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

The tool has zero parameters, so there is no parameter semantics to explain. The baseline for a zero-parameter tool is 4, and the description appropriately focuses on outputs and usage rather than inventing parameter details.

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

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

The description states a specific onboarding action: it returns a link for the user to sign in or sign up, upload a selfie, and run the free photo check, plus a connection_key. It distinguishes itself from siblings by saying 'Start here to make photos' and that the key is needed for every account tool.

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 explicitly says to start here to make photos and to call it only once per conversation unless the key stops working. This gives clear when-to-use and when-not-to-use guidance without requiring 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 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 already declare destructiveHint=false and readOnlyHint=false, and the description adds genuinely useful detail beyond them: the account, photos and credits persist after unlinking. That spells out the blast radius of the call, which the hints only gesture at. It stops short of saying whether the connection_key is invalidated or whether the call is reversible, and idempotentHint=false goes unexplained.

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, both load-bearing: the action first, the preservation guarantee second. Nothing is redundant or buried.

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 mutation with no output schema, the description covers the action and the preservation guarantee, which is the crucial part. It does not say what happens on success or failure, or what state the conversation is left in, which leaves a modest gap for an agent verifying the outcome.

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 schema itself already documents connection_key's origin and secrecy requirement, so the description adds no parameter meaning. With the schema doing the heavy lifting, baseline 3 is appropriate.

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

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

The description gives a specific verb and resource: "Unlinks this conversation from the user's DatingProfile account." The scope (this conversation, not the whole account) is clear and implicitly distinguishes it from connect_account, though it never names that sibling explicitly.

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

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

Usage is implied by the verb 'unlink' — you call it when the user wants to sever the conversation-to-account link. However, there is no explicit when-to-use, no prerequisite (e.g., must already be connected), and no mention of connect_account as the inverse operation, so the agent must infer routing.

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 useful context – it is a free check over previously uploaded selfies – but leaves a key behavioral question open: whether this only fetches an existing result or triggers computation, and what happens when no check exists yet. With annotations carrying the safety burden, a 3 is appropriate.

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 dense sentence front-loads the identity of the result and then enumerates its contents, followed by a short instruction sentence. Every clause carries information, though the long enumeration list makes it slightly run-on.

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 appropriately enumerates the return payload, which is exactly what an agent needs. The remaining gap is state behavior – error or empty-result handling when no photo check has been run – plus no explicit sibling routing, keeping it below 5.

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?

Only one parameter, and schema coverage is 100% with a self-contained description of connection_key including the 'never show it to the user' warning. The tool description adds nothing about connection_key, so the baseline 3 applies; the schema does all the work here.

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 resource (the DatingProfile photo check of uploaded selfies) and enumerates exactly what it returns: overall score, potential, five category scores with findings, per-photo notes, and missing photo types. That makes it distinguishable from get_photos (raw photos) and create_photos. It does not, however, distinguish itself from photo_review_guide or recommend_styles, which sound adjacent, so it falls short of a 5.

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

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

Usage is only implied: the tool applies to selfies the user already uploaded, and the description instructs to 'explain it... then suggest styles for what is missing' – loosely routing to recommend_styles. There is no explicit when-to-use or when-not-to-use versus get_photos, photo_review_guide, or recommend_styles, and no stated prerequisite (e.g. that a check must already exist).

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 establish readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds business-critical context not present in structured fields: prices are in USD, all payments are one-time, and nothing renews — the last point materially shapes how an agent communicates cost to a user. It stops short of describing the shape of the listing (e.g., per-pack rows with names and amounts).

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, no renewal) is front-loaded. Nothing is repeated from 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?

For a simple zero-parameter lookup with no output schema, the description supplies enough — what is priced, in what currency, and the billing model — for an agent to call it and set user expectations. It could add one clause on what the response contains (a list of packs/top-ups with amounts), which is the only real gap.

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; baseline for a zero-parameter tool is 4. The USD mention is the only semantic detail, and it applies to the values rather than to 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 description names the resource and its contents (DatingProfile packs and top-ups, priced in USD), which distinguishes it from siblings like buy_pack or account_status. It lacks an explicit verb such as 'returns prices for,' so the agent must infer that this is a read-only price lookup rather than a purchase action, but the intent is unambiguous in context.

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 it should call this to see costs before calling buy_pack, but the description never states that relationship or names any alternative. With zero parameters and a read-only profile the gap is low-risk, but no explicit when-to-use or when-not-to-use guidance is given.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without description help. The description contributes the useful fact that the catalogue is 62 styles total, but leaves out how filters combine and whether previews have a cost or latency impact. A minor tension exists: it says previews show 'example photos of each style' while the schema caps it at 'up to 8' matching styles.

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 resource and its size, then filtering and then the preview option. Nothing is padded, though the parenthetical '(scenes)' is the only concession to redundancy and the opening noun phrase would read more decisively as a verb.

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, filter-only listing tool with no output schema and zero required parameters, this covers the essentials: what the items are, how many, how to narrow, and how to get images. The remaining gap is not stating what each returned style contains (name, id, category) that a downstream create_photos call would need, plus the filter-combination rule.

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%, so the schema already carries most parameter meaning, and the baseline of 3 applies. The description confirms the three filtering dimensions but adds no semantics the schema lacks — notably it never says whether search, category and photo_type are AND-ed together, which is the one clarification that would materially help.

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 resource (62 photo styles/scenes) and the operations available on it (filter by category, photo type, or word; optionally include previews), so an agent knows exactly what it returns. It stops short of a leading verb and never explicitly contrasts itself with the sibling recommend_styles, which is the main ambiguity for selection.

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 rather than stated: 'Filter by category, photo type or a word' tells how to narrow results and 'Set show_previews to see example photos' tells how to enrich them. There is no explicit when-to-use guidance and no exclusion pointing to recommend_styles as the alternative when the user wants a suggestion rather than a browsing list.

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 behavior. The description adds useful scope beyond that: pre-account, in-chat review and the boundary with the official scored photo check. It does not describe the return format, but for a static checklist with no parameters the added behavioral context is solid.

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 tight sentences with no wasted wording. The first defines the resource and its scope; the second immediately clarifies the alternative official check.

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 guide with no output schema, the definition covers what it is and when it applies. It could say more about what the checklist contains or returns, but nothing required to invoke it correctly is missing.

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

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

There are zero parameters and the empty schema is fully covered. The description does not need to explain parameter meaning, so the baseline of 4 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 the specific resource: DatingProfile's checklist for reviewing dating profile photos shared in chat before account creation. It also distinguishes itself from the official scored photo check that runs on upload, so an agent can tell it apart from sibling get_photo_check.

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

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

Gives a clear context for use—reviewing photos the user shares in chat before they have an account—and names the alternative scored check for uploads on datingprofile.app. It does not explicitly say when not to use other photo-related siblings like create_photos or recommend_styles, so it stops short of fully explicit routing guidance.

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

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

Annotations already 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.