Velox TriFit

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

Goes well beyond the annotations by disclosing that the attempt consumes allowance, that a timeout does not mean the request failed to run, that the request ID must not be replaced, and that the original receipt should be checked. This is exactly the failure-mode and cost context an agent cannot get from destructiveHint/idempotentHint alone; no contradiction with 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?

Front-loads the approval precondition, then cost and failure semantics in short declarative sentences. Dense but every sentence carries operational weight; only 'Check the original receipt' is terse enough to be slightly ambiguous.

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 destructive, allowance-consuming submission with an output schema present, the description covers approval gating, cost, non-retry policy, ID stability and timeout interpretation. Nothing an agent needs in order to call it safely 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?

Schema coverage is only 25%: requestId carries a description, but productAssetId and personalAssetId are undocumented in the schema. The description compensates by specifying these are two *existing account* image IDs (not uploads), and 'explicit user approval' explains the permissionConfirmed const-true gate.

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: submit one DressMe request using two existing account image IDs, and explicitly separates itself from the guest demo path. It does not name the closest sibling (create_try_on / get_trifit_try_on) directly, so the routing is inferred from 'account' vs 'guest' 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?

Gives a hard precondition ('Only after explicit user approval') and a scope condition ('uses the website queue and existing account allowance, not the guest demo'), which implicitly routes guest-demo callers elsewhere. It stops short of naming the alternative tool explicitly.

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?

Adds real context beyond the annotations: consumption of one session attempt and one shared daily attempt, a 1-per-session / 10-per-day cap, non-retry guidance, and that the call returns a receipt rather than a result. That explains why destructiveHint=true matters (attempts are burned), though it never says what is destroyed or whether the uploads remain usable after a failure.

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?

Six short sentences, front-loaded with the permission precondition, then invocation method, then cost limits, then the follow-up pointer to get_try_on. No filler and every sentence carries 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 metered, consent-gated generation tool it covers preconditions, both invocation modes, quota cost, retry policy, and the receipt/get_try_on workflow, and an output schema already documents the return shape. The remaining hole is the undocumented required 'consent' boolean and the absence of sibling differentiation.

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

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

Schema description coverage is 0% across 5 parameters including two nested image objects, so the description has to carry weight. It does clarify the crucial mutual exclusivity the schema cannot express (images in ChatGPT vs. the two asset IDs in Codex, 'use one method, not both'), but it never explains the consent field, nor why download_url and file_id are jointly required.

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 ('Generate a DressMe virtual try-on') plus the inputs it works from, which is far more than a restated name. It does not, however, differentiate itself from the sibling create_trifit_try_on, so an agent must infer which try-on flavor applies.

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 precondition ('only after their explicit request and permission') and explicit exclusions ('Do not automatically retry or bypass limits'), plus environment-specific invocation routes. Missing is any routing advice versus create_trifit_try_on or the upload/prepare siblings named in the tool 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 read-only, closed-world, idempotent, non-destructive behavior. The description adds useful context beyond annotations: documents are public only, the response includes an official source URL and deployed content checksum, and arbitrary URLs/private files are not supported.

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 tightly written sentences with the main action and scope front-loaded, followed by exclusions. Every sentence adds relevant information without repetition.

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 one-parameter read tool with an output schema and rich annotations, the description is complete: it covers purpose, valid input source, return provenance, and unsupported inputs. Nothing essential for 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?

Schema description coverage is 0%, so the description must carry parameter meaning. It does meaningfully explain that the single 'id' parameter is an ID returned by search rather than a URL, though it does not explain the individual enum document IDs beyond the enum values themselves.

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

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

The description states a specific verb and resource: read the full public document for an ID returned by search. It adds scope and provenance details (official source URL, deployed content checksum) and explicitly excludes arbitrary URLs and private files, which distinguishes it from search and from a generic URL fetcher.

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 clearly indicates when to use the tool: for an ID returned by search, and explicitly says it does not fetch arbitrary URLs or private files. It does not compare against the sibling tools get_integration_example or get_partner_access_requirements, so alternatives are not fully addressed.

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 useful behavioral context by clarifying that the read is scoped to the private guest-session allowance and its perSessionLimit denominator, and that it does not upload images or generate anything.

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

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

The description is two sentences, front-loads the read action, and adds the non-generation constraint without redundancy. Every sentence contributes to understanding the 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?

With zero parameters, full schema description coverage, and an output schema present, the description does not need to explain return values. It sufficiently identifies the resource being read and rules out side effects, making the definition complete for correct invocation.

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

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

The tool has zero parameters, so the baseline score is 4. The description does not need to explain parameter semantics, and the empty schema is consistent with the definition.

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 specific verb ('Read') and a specific resource ('current private guest-session allowance and its perSessionLimit denominator'), so the purpose is clear. It distinguishes itself from upload/generation tools by stating it does not upload images or generate anything, but it does not explicitly differentiate itself from the sibling get_trifit_allowance.

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

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

The description implies that this tool should be used when the caller needs the current guest-session allowance rather than when preparing uploads or generating try-ons. However, it gives no explicit when-to-use guidance, no prerequisites, and no named alternative such as prepare_guest_upload, leaving usage context mostly inferred.

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 read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful context beyond those annotations by clarifying that the example uses dummy local responses, makes no cloud calls, and incurs no generation charges.

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 tightly written sentences front-load the resource and then add only useful constraints: language availability and offline/no-charge behavior. No sentence 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 low-complexity, one-parameter tool with annotations and an output schema, the description is complete enough to call correctly. It explains what is retrieved, which languages are supported, and the offline behavior, without needing to restate the output schema.

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

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

Schema description coverage is 0%, but the single required `language` parameter has an enum. The description compensates well by explaining that JavaScript maps to a runnable integration example and TypeScript maps to accompanying declarations.

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: retrieving a runnable JavaScript/Node.js integration example or TypeScript declarations. It clearly identifies the artifact and its scope, though it does not explicitly distinguish itself from sibling tools such as fetch or search.

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 description: retrieve this when an offline JavaScript/TypeScript SDK example is needed. The note that other language SDKs are not released provides a language availability boundary, but there is no explicit when-to-use guidance versus alternatives or sibling tools.

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

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds real context beyond that: this returns guidance only, performs no provisioning, and explicitly does not guarantee a free allowance — a caveat an agent would otherwise over-promise.

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 positive purpose followed by the exclusion list. No filler, and every clause carries either scope or a caveat.

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 an output schema present and a rich annotation set, the description covers the remaining burden: what the tool is for and what it will not do. Return-format details are correctly left to the output schema, so nothing essential 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 no parameters, so there is nothing for the description to disambiguate; the baseline for zero-param tools applies. No parameter details are omitted because none exist.

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 (explain how to apply) and resource (manually provisioned Velox Partner API access), plus the key-handling advice. It does not explicitly contrast itself with siblings like get_integration_example or fetch, so an agent must infer the boundary, keeping it short of a 5.

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

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

The negative scoping ('Does not create accounts, issue keys, send an application or promise a universal free allowance') effectively tells the agent when this tool is the wrong choice, which is strong routing guidance for a zero-param explainer. It stops short of naming an alternative tool for the cases it excludes.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description reinforces this with a concrete list of operations it does not perform (no send, no mailbox inspection, no key issuance). That negative-space disclosure is genuinely useful for preventing misinvocation, though it does not describe the response shape.

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 purpose, then a scope boundary. The enumerated workflow stages are dense but serve as a useful preview of the guide's contents; minor redundancy between 'public guidance only' and the does-not list.

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 indicating what the guide returns, which it does by listing the workflow steps. For a zero-parameter read-only guidance tool with rich annotations, nothing critical for 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 of 4 applies. No parameter information is omitted that an agent would need.

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 ('Read the official in-chat Partner API application workflow') and enumerates the workflow stages (partner@v3lox.com, sender confirmation, draft preview, send approval, reply verification). It is clearly distinguishable from action siblings, though it does not explicitly contrast with the adjacent get_partner_access_requirements 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?

Provides clear context for use: it is public guidance, requires no TriFit account, and explicitly excludes sending email, inspecting a mailbox, submitting forms, issuing keys, or changing access. This tells the agent when not to reach for it, but it does not name which sibling to use instead for those actions.

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 read-only, idempotent, non-destructive, closed-world behavior. The description adds valuable context that this operates on a verified connection, distinguishes guest versus personal account state, and explicitly warns against using it for linking, switching, account creation, or trusting an email hint.

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

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

The description is two sentences and front-loads the core purpose before listing exclusions. Every clause earns its place by clarifying account-type detection and preventing misuse.

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?

The tool has no parameters, rich annotations, and an output schema, so the description does not need to explain return values. It is complete for a low-complexity identity check: it says what it determines, when to call it, and what it must not be used for.

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 are no parameter semantics to explain. The baseline for a zero-parameter tool is 4, and the description does not need to compensate for any schema description gap.

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

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

The description uses a specific verb-resource pair: identify whether the verified connection is a guest session or a personal TriFit account. It explicitly distinguishes this read-only identity check from account creation, linking, switching, or trusting an email hint, which separates it from siblings like get_trifit_profile and create_trifit_try_on.

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 clearly states the timing: use this before choosing tools. It also gives strong exclusions: does not link, switch, create an account, or trust a conversational email hint. The only gap is that it does not name sibling tools as alternatives, such as get_guest_demo_status for guest demo state.

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 that the tool is read-only, idempotent, non-destructive, and closed-world. The description adds useful context beyond that by clarifying that checking allowances does not reset or spend credits, which is especially relevant for an allowance-based resource.

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

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

The description is two short sentences with no wasted language. The core purpose is front-loaded, and the no-side-effect clarification follows immediately.

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 tool with annotations and an output schema, the description is largely sufficient. The only notable gap is that it does not explicitly route the agent relative to similar read siblings such as get_trifit_account.

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 are no parameter semantics to explain. The baseline score of 4 applies because the schema does not require additional description to invoke the tool correctly.

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 specific verb and resource: read daily, weekly, and monthly allowances, matching the TriFit website. It distinguishes itself from mutation-oriented siblings by stating it does not create, reset, or spend credits, though it does not explicitly distinguish itself from get_trifit_account or get_trifit_profile.

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: use this to view allowance levels and not to modify them. The description gives negative guidance by ruling out creation, resetting, and credit spending, but it does not name alternatives or state when to choose this tool over get_trifit_account.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds value beyond that by enumerating what the tool will NOT do (no creation, switching, uploads, generation), preventing an agent from expecting side effects. It stops short of saying what happens if the connection is unauthenticated or has no profile.

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, zero filler, with the positive statement front-loaded, the negative scope second, and the sibling routing last. Every sentence 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?

With an output schema and full annotation coverage, the description does not need to explain return values or safety. What remains thin is the meaning of 'stable profile' — an agent knows to call it but not precisely what identity fields come back. Adequate for a zero-argument, read-only lookup.

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?

Zero parameters, so there is nothing about inputs to explain; baseline is 4. The description appropriately spends no words on input semantics.

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 (read the stable profile of this connection) and scopes it against siblings by naming get_trifit_account. 'Stable profile' is somewhat abstract — it never says what a profile contains — but combined with the title and the routing sentence an agent can tell what this returns.

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 final sentence explicitly routes the agent to get_trifit_account for connection mode and allowance source, which is real when-to-use guidance. No explicit exclusion list beyond that, but the negative-scope sentence ('No account creation, switching, uploads or generation') guards against the most likely misuse.

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

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: 'A missing receipt means acceptance is uncertain, not that it never ran' — a non-obvious interpretation rule an agent would otherwise get wrong.

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 the core action front-loaded and no filler. The uncertainty caveat is well placed after the primary statement.

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?

An output schema exists so return values needn't be described, and annotations cover safety. However, for a tool with two opaque, optional UUID parameters, the unresolved jobId-vs-requestId ambiguity leaves an agent unsure how to invoke it.

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

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

Schema description coverage is 0% and both jobId and requestId are undocumented, and both are optional (0 required). The description never clarifies what jobId vs requestId mean, which one to supply, or whether either alone suffices — a real gap the description should have filled.

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

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

States a specific verb (Read) and resource (existing account DressMe/TriFit request) plus the returned fields (status, duration, result ID), and rules out generating/replaying. It does not explicitly distinguish itself from close siblings like show_trifit_try_on or get_try_on, so it falls short of a 5.

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

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

The phrase 'without generating or replaying' implies this is the read-only counterpart to create_trifit_try_on, but no alternative tool is named and no explicit when/when-not conditions are given. Usage is inferable rather than stated.

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 read-only and idempotent annotations, it discloses display behavior for include_image across ChatGPT and other MCP clients, a polling rate limit, and a replay prohibition for needs_review results. These are meaningful operational details that an agent would not get from the annotations alone.

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 four tight sentences, front-loaded with the read-only scope and then the important operational constraints. Every sentence adds distinct value with no repetition.

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 annotations covering safety, an output schema covering return values, and the description covering guest-session scope, image display behavior, polling limits, and replay restrictions, the definition gives the agent enough to invoke 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 description coverage is 0%, so the description must carry parameter meaning. It explains the include_image behavior well, but request_id is only indirectly described as an existing request belonging to the guest session, without stating where the caller obtains it or how it maps to prior create/prepare calls.

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

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

The description states a specific verb and resource: it reads an existing request tied to the authenticated guest session. It also distinguishes the operation from creation/retry and makes clear it returns a completed image when requested.

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 clear usage constraints: do not use it to create or retry a generation, poll no more than once every five seconds, and do not replay a needs_review result. It does not explicitly name sibling alternatives such as get_trifit_try_on, but the guest-session scope provides useful routing 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, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds useful scope details: only metadata is returned, no image bytes, and guest history is excluded. However, it says nothing about pagination behavior, ordering, or default limits beyond what the schema provides.

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 filler. The scope statement is front-loaded and the exclusion follows immediately, making the description easy to parse.

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?

The output schema and annotations reduce what the description must cover, and the scope/exclusion sentences are useful. Still, for a three-parameter list tool with 0% schema description coverage, the description leaves pagination and the kind enum's 'all' behavior 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?

Schema description coverage is 0%, so the description must compensate for all three parameters. It partially maps to the kind enum by listing 'photos, products, looks and DressMe requests,' but it does not mention the 'all' value, limit, offset, or pagination semantics.

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 specific verb and resource: 'Read metadata for your saved personal photos, products, looks and DressMe requests.' This clearly identifies the tool as a metadata listing endpoint, though it does not explicitly differentiate itself from siblings like get_trifit_account or search.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as get_trifit_try_on, search, or fetch. The exclusion 'No guest history transfer' hints at a boundary but does not name alternatives or state when this tool is preferred.

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 this is a non-destructive, non-idempotent, closed-world write. The description adds genuinely useful behavior beyond that: the URL is single-use, bytes must be PUT to the returned URL, JPEG/PNG/WebP are auto-resized, and only one upload per role per guest session is allowed. It omits URL expiry/auth details, keeping it below a 5.

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 context tag 'For Codex/local files' is front-loaded and each following sentence adds a distinct constraint (single-use URL, no disclosure, format support, quota, no try-on). The 'do not disclose that capability' instruction is unusual but still short and purposeful.

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?

An output schema exists, so the description needn't document the response, and it still usefully refers to the 'returned URL'. Given one enum parameter and clear annotations, the description covers the call mechanics, quota, and format handling; only URL lifetime and the credential/context requirements for the PUT are absent.

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

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

Schema coverage is 0%, so the description has to carry the burden for the single `role` enum. It does map the enum values to meaning ('personal photo or product image') and notes the one-per-role limit, which compensates partially, but it never explicitly defines which enum value corresponds to which scenario or confirms the parameter is required.

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

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

The description names a specific action (reserve a single-use HTTPS PUT upload) and the resource scope (personal photo or product image for a guest session), and it explicitly rules out try-on generation, which separates it from create_try_on/create_trifit_try_on siblings. It never names prepare_trifit_upload, so the distinction from that near-twin is left 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?

'For Codex/local files' and 'At most one upload per role per guest session' imply when this applies, and the closing sentence excludes try-on usage. However, there is no explicit guidance on choosing this over prepare_trifit_upload or on what happens if the one-per-role quota is already consumed.

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?

Goes well beyond the annotations: the URL is one-use and expires in five minutes, the PUT resizes and slots the image into the connected account library (personal vs product behaviour), description prep is cached for products, and the caller must preserve clientImportId and assetId. The no-retry rule discloses the non-idempotent failure semantics that idempotentHint=false alone would not make actionable.

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?

Front-loaded with the core action (create a one-use upload URL) and every following sentence adds a distinct operational constraint. It is dense and somewhat run-on, packing PUT mechanics, storage effects, and retry policy into one paragraph, but little 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?

An output schema exists, so return values need no explanation, yet the description still tells the agent what the returned assetId is for. Authentication posture (no API/OAuth headers), size/type limits, retry policy, and the personal-vs-product distinction are all covered for a mutation-adjacent tool.

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

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

Schema coverage is only 33%, so the description must compensate. It explains the consequence of role ('product images use cached description preparation' vs website photo slot) and reinforces clientImportId as the stable import key that survives an uncertain upload; permissionConfirmed is only covered indirectly via 'with explicit permission'.

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 concrete verb+resource: 'create a private, one-use upload URL valid for at most five minutes' for a user-selected local file. The final sentence ('Preparing does not upload or generate') implicitly separates it from upload_trifit_image and create_trifit_try_on, but no sibling is named 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?

Gives clear preconditions ('user-selected local file in Codex, with explicit permission') and hard rules: PUT only JPEG/PNG/WebP raw bytes, no API/OAuth headers, no redirects, never retry an uncertain upload. It does not explicitly name which sibling to use when the file is remote or when the user wants a try-on instead of an upload.

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 safety is covered. The description adds a genuine scope boundary (only the deployed public corpus, no private or staged docs), but says nothing about query interpretation (keyword vs natural language), result ranking, or result count limits.

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 with no filler; the subject and corpus scope come first. The embedded topic enumeration is dense but functional, reading slightly like keyword stuffing rather than guidance.

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?

An output schema exists, so return-value explanation is unnecessary, and the corpus scope plus topic coverage is enough to decide when to invoke it. The remaining gap is query authoring guidance for the sole, wholly undocumented parameter.

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

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

Schema description coverage is 0% for the single 'query' parameter (it carries only minLength 1 and maxLength 200), so the description is the only place query semantics could be explained. The topic list hints at useful search terms but gives no syntax, phrasing, or format guidance to compensate for the coverage gap.

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

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

States a specific verb (Find/Search) plus the resource (official Velox DressMe integration documentation) and enumerates the covered topics, so an agent knows exactly what corpus is being queried. It does not explicitly contrast with the sibling 'fetch' tool, which is the main candidate to confuse it with, 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?

"Searches only the deployed public documentation corpus" implicitly frames usage (public docs lookup, not partner-internal data), but there is no explicit when-to-use/when-not, and no routing advice toward fetch, get_integration_example, or get_partner_access_requirements even though those siblings overlap with the topics listed.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the description earns credit for adding context beyond them: the separate private-image permission requirement and the fact that no allowance is consumed. It doesn't say what happens if permission is missing or how the image is rendered.

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 with no waste; the core action leads and the constraint/cost notes follow. Every sentence carries information.

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

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

An output schema exists so return values needn't be described, and the safety profile is covered by annotations plus the permission note. The remaining gap is parameter guidance: with 0% coverage and two mutually ambiguous UUIDs, an agent lacks what it needs to call the tool correctly.

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

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

Schema description coverage is 0% and neither jobId nor requestId is explained in the description. With two UUID parameters whose distinct roles (job vs. request) are non-obvious, the description should clarify which identifier to supply, but it says nothing.

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 — displaying a completed DressMe/TriFit result inside the conversation — which is clearer than a bare name restatement. It doesn't explicitly differentiate from the sibling get_trifit_try_on (likely the metadata fetch), so an agent must infer the display-vs-fetch split.

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?

'Uses only the existing result; no generation, upload, public share or new allowance is used' implies this is a display-only path rather than a creation path, and the private-image permission note flags a prerequisite. However, it never names an alternative (e.g., create_trifit_try_on or get_trifit_try_on) or states when to prefer one.

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 the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), and the description adds substantive context beyond that: automatic resizing, writes to the website library, slot selection, and the cached-description path for product images. It still leaves unclear whether selecting a slot replaces or destroys a previously selected photo and what 'connected account' authentication entails, which is the one gap for a mutating tool.

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

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

Four compact sentences, with the permission precondition and the core action front-loaded, followed by side effects and prohibitions. No padding, though the 'cached description preparation' clause is dense enough that it takes a read to parse.

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 annotations covering safety and an output schema covering returns, the description needs only to cover preconditions and side effects, and it does both. Completeness falls slightly short on slot-replacement semantics and account/auth scoping, the two things an agent could get wrong on this call.

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 low (25%), so the description must help, and it does: it explains the personal-vs-product meaning of `role` (product images take the cached-description path), the significance of `permissionConfirmed` ('with explicit permission'), and constrains `download_url` by forbidding arbitrary URLs. It adds nothing for `file_id`, `file_name`, or `mime_type`, which remain undocumented.

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

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

The description states a specific verb and resource: import a selected personal or clothing image into the connected TriFit account, and it enumerates the downstream effects (resize, library save, slot selection). It implicitly distinguishes itself from the prepare_trifit_upload sibling by referring to 'the existing cached description preparation' as an upstream step, but it never names the sibling outright.

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 real conditions and exclusions: requires explicit permission from the user, never import arbitrary URLs, and never retry an uncertain import automatically. That's clear when/when-not guidance, though it doesn't explicitly route the agent to prepare_trifit_upload for the preparation step or to list_trifit_library for verification.

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