Clickwise Affiliate Network

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true), the description discloses the auth requirement (own Clickwise affiliate API key via X-API-Key or Bearer), the account scoping ('acts only on your account'), and the outcome model ('approved or pending'). That is exactly the behavioral context an agent needs before invoking a mutation.

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 the action and the ID source before auth details. Dense and largely waste-free, though the parenthetical about ID provenance is a little packed for a reader scanning quickly.

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 correctly supplies the return status (approved or pending) and the auth/account constraints. The remaining gap is the zero-required-parameter ambiguity (must one of program_id/campaign_id be supplied?) and the undocumented campaign_id origin.

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% and there is no type/format documentation, so the description must carry the load. It gives useful provenance for program_id (comes from list_my_programs with include_available) but says nothing about where campaign_id originates, its valid form, or whether exactly one of the two 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?

States a specific verb and resource ('Ask to join a program') and immediately anchors the identifier to the sibling that produces it (list_my_programs with include_available). An agent can distinguish this from list_my_programs, find_affiliate_programs, and the request_* siblings without opening any schema.

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

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

Explains where program_id comes from and that campaign_id is an accepted alternative, which tells the agent how to be ready to call it. It does not state when NOT to apply or what the alternative route is if the agent lacks an ID, so it stops short of full when/when-not 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?

Goes beyond the annotations by disclosing partial-failure semantics ('a failed item never blocks the others'), the idempotent 'or return existing' behavior (consistent with idempotentHint), and the auth mechanism (X-API-Key or Bearer on the MCP connection). The account-scoping note ('acts only on your account') adds useful context. Missing return-value detail, but strong overall.

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

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

A single dense paragraph, front-loaded with the core action, followed by per-item behavior and auth. Every clause carries information; the auth sentence is slightly tangential but earns its place for a write 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?

For a write tool with no output schema, the description covers action, scope, idempotency, partial-failure behavior, and authentication. The main gap is that it does not describe what a per-item status report looks like, but the essentials for correct invocation are present.

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?

Reported schema coverage is 0%, so the description must compensate. It explains subid tagging and landing_url deep-linking and the 'one per item' array semantics, but never clarifies the program_id vs campaign_id alternative that the schema exposes, nor the maxItems=20 cap. Partial compensation.

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 ('Create (or return existing) tracking links') plus the scope ('for programs you are approved in') and per-item granularity. This clearly distinguishes it from siblings like request_tracked_links and get_tracked_link_request.

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?

Implies usage context ('programs you are approved in', 'one per item') but never explicitly says when to use this versus request_tracked_links or get_tracked_link_request, nor names any prerequisites or exclusions. Adequate but leaves the sibling routing to inference.

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

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

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description adds real behavior an agent cannot infer: the auth mechanism (X-API-Key or Bearer), that it acts only on the caller's own account, the 366-day cap with a 30-day default, and that daily/weekly/monthly series include empty periods.

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

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

A single dense sentence with no filler, and the highest-value content (what is returned) is front-loaded. The run-on auth clause at the end is slightly heavy but still 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?

No output schema exists, so the description carries the burden of describing the return shape, and it does (grouped conversion and commission figures, empty periods retained). Remaining gaps are the filter semantics of subid/status, which are minor for a read-only report.

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 40% and 5 parameters exist, so the description must compensate. It usefully covers group_by values and the date window, but frames subid and status only as grouping dimensions rather than explaining their filter behavior, leaving that half of the parameters thin.

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 ('Your conversions and commission... grouped by day, week, month, subid, campaign or status') with the aggregation dimensions and window spelled out. An agent can distinguish this reporting tool from list_conversions or get_catalog_stats without opening the schema.

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

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

Gives operational context (default last 30 days, 366-day max, API key required) but never says when to choose this over list_conversions or how the subid/status filters interact. Usage is implied rather than contrasted with alternatives.

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 readOnly/idempotent/non-destructive, so safety is covered; the description goes further by disclosing the auth requirement (own Clickwise API key via X-API-Key or Bearer) and the default 90-day window. It does not explain pagination behavior or result ordering, which keeps 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?

Two tight sentences, front-loaded with what the tool returns and followed by the auth constraint. Every clause carries information; only the parenthetical auth detail slightly crowds the core purpose 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?

With no output schema, the description usefully names the returned fields and the per-subid rollup, and it covers the auth and account-scoping requirements. It stops short of describing pagination limits/defaults, which matters for a 6-param list tool with page_size up to 500.

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% across 6 params, so the description must compensate and it partially does: status, subid and the date range ('default: last 90 days') are implied. But page and page_size, which govern result volume, get no mention in either place, leaving a real 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 resource (individual conversions) and enumerates the returned fields (status, commission, currency, subid, plus a per-subid rollup), so an agent knows exactly what this tool produces. No sibling tool in the list deals with conversions, so the resource is self-differentiating from get_performance_report and the rest.

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 context — default window of the last 90 days and that it acts only on your own account — which implies when it applies. However it never names an alternative (e.g., get_performance_report for aggregate stats) or states any exclusion, so the when-to-use-vs-sibling decision is left to inference.

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

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

Annotations already declare readOnlyHint, 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, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real value beyond that: the required X-API-Key/Bearer credential on the MCP connection, and the account-scoping constraint ('acts only on your account'). Pagination behavior is not disclosed.

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 waste, and the core scope ('Programs you are approved to promote') is front-loaded before the optional-flag hint and the auth caveat. Every sentence carries distinct 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?

With no output schema, the description helpfully names what is returned (link readiness, link count), and it covers the auth requirement and account scope. The main remaining gap is pagination/default behavior for page and page_size, which matters for a list tool with a 200-item cap.

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 25% (just 'search'), so three of four parameters are undocumented. The description explains include_available's semantics ('also list programs you can apply to'), which is genuine added meaning, but page/page_size remain unexplained anywhere. Baseline for high coverage would be 3; here the partial compensation lands at the same level.

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: programs the authenticated user is approved to promote, plus link readiness and existing link count. It distinguishes itself implicitly from list_programs/find_affiliate_programs by the 'approved to promote' qualifier, but never names a sibling to route against, 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?

Gives a clear conditional instruction ('Set include_available to also list programs you can apply to') and states the auth prerequisite. It does not name an alternative tool for program discovery (e.g. find_affiliate_programs) or say when not to use this, so no exclusions are given.

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

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

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.