Clickwise Product Catalog & Affiliate Links

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), and the description adds meaningful context beyond them: results are 'live' programs, they are ranked by fit, and no signup/auth is required. It stops short of disclosing return shape or result limits, but that is a modest gap given the annotation coverage.

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 scope and ranking behavior front-loaded and zero filler. 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 an 11-parameter, no-output-schema discovery tool, the description supplies the essential framing (live programs, fit ranking, no signup) and the schema carries the parameter detail. It could note what a result contains or how it relates to the tracked-link siblings, but it is largely sufficient.

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 91%, so the schema already documents nearly all 11 parameters. The description only echoes the channel dimension ('site, app, newsletter or social channel') and adds no syntax, defaults, or interactions beyond what the schema provides. 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?

States a specific verb ('Find') and resource ('live Clickwise merchant programs') scoped to a publisher's channel, plus the ranking basis ('ranked by fit'). It distinguishes itself from enumeration siblings like list_programs only implicitly through the discovery/ranking framing, with no explicit sibling callout.

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?

'Does not require signup' and the channel framing imply the discovery context, but there is no explicit when-to-use vs when-not, and no routing to alternatives such as list_programs or get_monetization_feed. Usage must be 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 cover read-only, idempotent, non-destructive behavior, so the description earns credit for adding caching semantics (fixed one-hour validity) and staleness semantics (snapshot_stale marks older counts served for under six hours), plus an explicit scope exclusion (no affiliate data or amounts). It doesn't explain the response shape or how generated_at is produced.

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 sentences, front-loaded with what is counted and as of when, followed by staleness rules and scope exclusions. Dense and jargon-heavy ('served for less than six hours'), but 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?

With no output schema, the description partially compensates by naming the returned fields (counts, generated_at, snapshot_stale) and their semantics. For a zero-parameter read tool this is close to complete, though it never says what the counts are of beyond 'GTIN catalog'.

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 clarify; the baseline for a zero-parameter tool applies. The description instead spends its words on the returning metrics, which is the right trade-off.

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: returns public GTIN catalog counts. The resource is unique among siblings (all of which concern deals, news, programs, products, tracked links, or profile), so an agent can distinguish it immediately.

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 explains freshness semantics (one-hour validity, snapshot_stale window) but never states the scenario in which an agent should call this tool, e.g. to report catalog size or freshness. Usage is only implied by the tool's subject matter.

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 safety profile is fully covered structurally. The description adds only that the response is a full record in the requested language; it says nothing about not-found behavior, permissions, or rate limits, so it adds modest value on top of 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?

Two front-loaded sentences with no filler, the identification method ('by its slug') stated first. The trailing 'etc.' makes the return-field list slightly vague but it is efficient overall.

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 two-parameter read with no output schema, the description gives the identifying key, the language option, and a sample of returned fields, while annotations cover safety. Nothing critical is missing for correct invocation, though not-found/error behavior is unstated.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains that 'slug' identifies a single deal and that 'lang' selects the response language, covering both parameters beyond the bare schema. It doesn't state the enum values or the default, which are visible in the schema anyway.

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 ('Fetch the full record for a single deal by its slug'), which clearly separates it from list_deals and search_products. It doesn't explicitly name the sibling it contrasts with, so sibling differentiation is implied rather than stated.

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

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

Usage is implied: fetch one deal when you already have its slug, versus list_deals for browsing. There is no explicit when-to-use/when-not guidance or named alternative, so it stays at the minimum viable level.

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 flag it as a non-read-only, non-idempotent, non-destructive write operation, and the description adds meaningful context beyond that: the affiliate is only 'provisional', email is optional, and the account is claimed later for payout. That discloses the delayed-claim lifecycle detail an agent would otherwise miss. It does not state auth requirements or rate limits, keeping it short of 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?

One dense sentence that front-loads the creation behavior and the returned formats. No filler, though the packed clause structure requires a careful read and somewhat buries the distinguishing output description.

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 work of naming the three return formats (cards, HTML embed snippet, JSON feed), which is the key information for this tool. It also flags the side-effect and delayed payout lifecycle. Given 8 all-optional parameters, it is adequate without being exhaustive.

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 8 parameters are already documented in the schema. The description only adds meaning to claim_email ('optional; the account is claimed later for payout'), leaving the other parameters to the schema. 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 uses a specific verb ('Create') and names the resources involved (provisional Clickwise affiliate, tracked links) plus the returned artifacts (cards, HTML embed, JSON feed). It explicitly distinguishes itself from the sibling request_tracked_links by describing both its relationship to it and its different output. The only weakness is the 'get_monetization_feed' name, which reads as read-only while the description reveals a creation side effect.

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 the use case ('for a publisher's site or app') and positions itself as an alternative to request_tracked_links, but never states explicitly when to choose this over that sibling. An agent must infer that the embed/feed output is the deciding factor.

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 safety profile is fully covered. The description adds the useful behavioral note that it returns the 'full record' (contrasting with the partial list view), but says nothing about return format, caching, or missing-slug behavior.

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 front-loaded sentence with zero filler; the lookup key follows immediately after the purpose. 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?

With no output schema and a simple read tool, the description is close to sufficient, but it leaves the lang parameter unexplained and does not state that the slug originates from list_news. Adequate but with recognizable gaps.

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 the load, but it only explains the 'slug' parameter and gives no semantics for 'lang'. The enum values and default are visible in the schema, but the description never confirms that lang selects the localized article (and what happens with unsupported translations).

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 ('Fetch') and resource ('full record for a single news article'), with the lookup key ('by its slug') made explicit. The word 'single' implicitly separates it from the sibling list_news, though the sibling is never named.

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 'by its slug' implies the caller must already have a slug (presumably from list_news), so usage is implied rather than stated. There is no explicit 'use this instead of list_news when...' routing guidance or precondition statement.

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

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

It goes beyond the annotations by disclosing real behavioral traits: the URL is signed, links are Clickwise /dl/-tracked, the operation is idempotent in a user-visible way ('the same request returns the same URL'), and external factors (freshness, permissions, assignments, delivery caps) can affect the result. This aligns with idempotentHint=true and readOnlyHint=false without contradicting them.

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 sentences, each carrying distinct information (capability, return value, idempotency, prerequisites), with the core action front-loaded. Slightly dense but no filler.

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 three-parameter, no-output-schema mutation tool, it covers the action, return artifact, idempotency, auth requirement and constraints. The main gap is the undocumented category parameter and any indication of error or cap-exceeded 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 0%, so the description must carry all parameter meaning. It documents country ('one country') and format ('json, csv, tsv or xml') but never mentions the category parameter, leaving one of three parameters completely unexplained.

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

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

The description gives a specific verb-and-resource pairing ('Create or refresh a GTIN product feed') plus the concrete outcome (a signed URL with tracked product links), so the agent knows exactly what the tool produces. It stops short of differentiating itself from siblings such as get_monetization_feed, which could plausibly return similar feed artifacts.

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

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

It sets preconditions (authenticated affiliate API key, one country, freshness/permissions/assignment/delivery-cap constraints) which is useful context. However, it never states when to prefer this tool over get_monetization_feed or get_catalog_stats, and gives no explicit exclusion or alternative 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, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds that it returns specific data (affiliate RefId, review status, issued links) and requires an access secret. It does not disclose error conditions, rate limits, or secret sensitivity, but adds useful return context beyond 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?

The description is a single, front-loaded sentence with no wasted words. The list of returned fields is efficient, though it is slightly dense and could benefit from clearer structure.

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

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

With no output schema and annotations covering the safety profile, the description does supply the return contents and the required key. However, the unexplained 'application_id' and lack of usage context leave meaningful gaps for a tool with 0% schema coverage.

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%. The description only mentions 'access secret' as the key, which restates the parameter name without adding format or source. The required 'application_id' parameter is completely unaddressed, so the description barely compensates for the missing schema documentation.

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

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

The verb 'Fetch' and the specific resource 'instant-link request, affiliate RefId, review status, and issued links' clearly state what the tool does. It also specifies the retrieval key ('access secret'). However, it does not explicitly distinguish this from siblings like request_tracked_links or list_deals, though the scope is narrow.

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 guidance or mention of alternatives. The description implies it is used to fetch a request by access secret, but offers no prerequisites, exclusions, or context about when this tool is preferred over similar siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds only the "active" scoping word; it says nothing about pagination behavior or result volume despite limit defaulting to 20 and capping at 100.

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 front-loaded sentence with zero filler; the verb, resource and filter options are all in the first clause.

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 list tool with no output schema and annotation coverage of the safety profile, the description is nearly sufficient. The gaps are pagination/result-shape and the fact that the network filter only applies to signed-in affiliates, which matters for correct invocation.

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

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

Schema description coverage is 67%, and the description names four of the six filters (lang, category, country, merchant), matching what the schema already documents for three of them. It omits limit and network entirely, so it neither compensates for the undocumented lang/limit fields nor adds syntax beyond the schema.

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

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

The description states a specific verb (list) and resource (active Clickwise deals and offers) and names the filter dimensions. It is clearly distinguishable from get_deal (single item) and list_programs, though it does not explicitly contrast itself with those siblings.

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

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

"Optionally filtered by..." implies the retrieval use case, but there is no explicit when-to-use guidance, no mention of when to prefer get_deal or search_products, and no statement of prerequisites.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety and consistency profile is fully covered. The description adds only topical scope, no pagination, ordering, or defaulting behavior, which is acceptable given the annotation coverage but adds little.

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 front-loaded sentence with no filler; the resource and its scope appear 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?

With no output schema and 0% parameter description coverage, the description should carry the burden of explaining the returned item shape and filters, but it does neither. For a four-parameter filtered list tool, this leaves an agent guessing about defaults and result structure.

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 four parameters (lang, limit, network, severity), and the description explains none of them. The severity enum (info/warn/critical) loosely maps to the listed news categories, but language, result cap, and network filtering are left entirely 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?

States a specific verb ('List') and resource ('Clickwise news announcements about affiliate programs') and enumerates the content types covered (policy changes, launches, shutdowns, commission updates). It is clear what the tool returns, but it never distinguishes itself from the sibling get_news, leaving the list-vs-get split to inference.

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?

No when-to-use or when-not-to-use guidance, and no prerequisite or alternative named. An agent facing both list_news and get_news gets no signal about which to pick.

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 destructiveHint=false, so the safety profile is covered structurally. The description adds only that results are "live" (active programs) and paginated; it says nothing about result ordering, rate limits, or what happens with the network filter beyond the schema's own note.

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 first defines the operation and filters, the second routes the agent relative to the sibling tool. No filler.

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, no-required-param listing tool with no output schema, the description covers purpose, filters and the sibling relationship adequately. It omits any hint of the returned item shape or pagination termination, which would help but is not strictly required.

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 57%, and the description names only three of the seven filters (merchant, category, country), leaving page, page_size, network and ready_only to the schema. It adds no syntax or format guidance (e.g. merchant name vs domain) beyond what the schema already provides.

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+resource+scope: browse and paginate live programs, filterable by merchant, category or country. It also explicitly positions itself against the sibling find_affiliate_programs, so an agent can distinguish the two without opening a 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?

"Use it to go beyond find_affiliate_programs' top matches" gives a clear selection condition versus the closest alternative. It stops short of stating when NOT to use it (e.g. for a single known program) or any auth prerequisites for the network filter.

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 (readOnlyHint=false, idempotentHint=false, openWorldHint=true) by disclosing the stateful, multi-turn interview loop and the possible outcomes (follow-up question, approval, decline). It also notes the response carries a status and an access secret needed to continue, which is valuable since there is no output schema. It stops short of stating auth requirements or what happens to abandoned/duplicate applications.

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, front-loaded with the action, then the interaction outcome. No filler or repetition of the title or annotations.

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

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

For a 7-param, zero-required, no-output-schema tool, it explains the call flow and the returned status/secret, which covers the biggest unknowns. It leaves gaps on how the access secret is subsequently used and on the undocumented parameters.

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 only 43% (3 of 7 params), so the description is expected to compensate, but it only gestures at the free-text store description. country, website, vertical, and company_name receive no meaning, format, or optionality guidance in either place.

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 (start a merchant/advertiser onboarding application) and immediately describes the interaction model (automated evaluator responds with question/approval/decline). This clearly distinguishes it from the read/discovery siblings like list_programs and get_product_feed.

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 begin onboarding a new merchant and to drive the interview via free-text. There is no explicit when-not guidance, no mention of what to do for an existing in-progress application, and no routing away from alternatives such as request_tracked_links.

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 openWorldHint=true, non-idempotent, non-destructive. The description adds meaningful context beyond that: a provisional account is created, only programs that can issue a link now are included, and claiming/payout is a separate later step. It does not warn that repeated calls create additional accounts, which matters given idempotentHint=false.

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 dense sentences with no filler; the core action and its result lead, and the lifecycle caveat follows. 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 12-parameter, non-idempotent open-world creation tool with no output schema and 42% schema coverage, the description is too thin. It does not explain the returned link structure or clarify most inputs, so an agent cannot confidently fill out the call from this definition alone.

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 42% with 12 parameters, so the description is expected to compensate but adds almost nothing about them beyond confirming claim_email is optional. topic, channel, country, category, limit, and both traffic fields are undocumented in both schema and description, leaving over half the surface opaque.

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?

Names a specific verb and resource ('Create a provisional Clickwise affiliate') plus the outcome ('return tracked links'), which is well beyond a tautology. It doesn't explicitly contrast against siblings like find_affiliate_programs or get_tracked_link_request, though the 'programs that can issue one now' scoping hints at the distinction.

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?

Sets up the workflow context clearly: the email is optional and the account is claimed plus payout details added later via update_profile (a named sibling). It doesn't state when NOT to use this or when to prefer alternatives such as find_affiliate_programs first, so it falls short of full 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 declare readOnlyHint=false, which could confuse an agent for a 'search' tool; the description resolves this by explaining it returns Clickwise /dl/ tracked links created for the affiliate the first time a product is returned. It also discloses auth requirements (X-API-Key or Bearer), delivery caps, and freshness constraints that annotations do not cover.

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 dense sentences, each carrying distinct information (scope, auth/return semantics, parameter conditionals) with no filler. It is packed rather than padded, though the parenthetical load makes it slightly heavy.

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 usefully explains what comes back (tracked links) and the constraints governing results. The main remaining gap is semantics for the text/brand/category filters, which the agent must infer.

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 7 parameters, so the description must carry the burden. It adds real meaning for gtin, country, and offset (market coverage, required-unless logic, pagination scope) but leaves text, brand, limit, and category completely unexplained, so it only partially compensates.

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 ('Search fresh GTIN products in the catalog your affiliate can deliver') and immediately scopes it with freshness, permissions, and delivery caps. An agent can distinguish this from siblings like get_product_feed or get_monetization_feed without opening either 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 concrete conditional guidance: country is required unless gtin is supplied, and offset paginates the currently deliverable subset. It also states the auth prerequisite. It stops short of naming an alternative sibling tool for cases where this search is the wrong choice.

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 destructive=true, idempotent=true, readOnly=false, so the safety profile is covered. The description adds real value beyond that: "Overwrites the fields provided" clarifies partial-update semantics, and it names the credential source needed for authorization. It does not describe response/error behavior, but with annotations doing heavy lifting this is a solid addition.

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 front-loaded sentences: verb+resource first, then credential source, then the audience/use case. Efficient overall, though the trailing "without leaving chat" clause is mild marketing filler rather than 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 destructive, 7-param mutation with no output schema, the description covers the essentials an agent needs: authorization provenance, that only provided fields are overwritten, and the intended actor. It omits return/error behavior, which is a minor gap given no output schema is defined.

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 only 14% (only payment_method is documented in-schema), so the description is expected to compensate. It does name five of the parameter concepts, but these largely mirror the schema property names and add no format or type detail (e.g., country code format, URL requirements), leaving the compensation partial.

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 ("Update") and resource ("creator's instant-monetization profile") and enumerates the mutable fields (claim email, display name, website, country, payment method). It is the only mutation tool among siblings that are all get/list/search/request operations, so an agent can distinguish it immediately.

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 ties invocation to a prerequisite — the application_id + access_secret returned by request_tracked_links — and gives a concrete use case (completing claim/payout details from chat). It stops short of stating when NOT to use it or naming alternatives, but the context is unambiguous.

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