TradeGraph

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

Annotations already cover read-only/idempotent/non-destructive, but the description adds substantial behavioral detail: the per-rule payload (kind, gate, who must act, applicable-from date, official source, checked date), the 180-day stale marker, that upcoming rules are included, and how omitted country is resolved. This is rich context well beyond the annotations.

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

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

Purpose is front-loaded and clear, but the prose is very dense and dominated by long illustrative lists (UV filters, FCC/RED/Giteki/ISED, Section 232, CBAM, EPR). The examples aid comprehension but the single sprawling passage is longer than needed to convey the same 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 carries the burden of explaining return values, and it does so thoroughly: it names the fields each rule returns and the product_traits field. Combined with parameter behavior it is complete enough for an agent to call it correctly.

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

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

Schema coverage is 100%, so every parameter is already documented in the schema. The description reiterates trait detection and the country-omission behavior, adding some cross-parameter meaning (rules triggered by code or trait) but not new syntax or examples beyond the schema. Baseline 3 applies.

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

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

The description states a specific job: surface the non-obvious rules a Korean exporter would miss beyond category compliance, and enumerates the rule families (blockers, approvals, duties, filings). It clearly reads as a compliance/regulatory blind-spot detector, distinct from siblings like country_brief or market_scan. It doesn't name a sibling tool explicitly, so it stops short of 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?

It gives real usage context: rules are triggered by HS code or product trait, 'pass description or traits,' and 'omit country to check every market in the plan's table.' It frames the tool as 'starting points, not legal advice' and as complementary to category compliance. It stops short of 5 because it doesn't explicitly say when to prefer a sibling or when not to use this.

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

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

The annotations already establish that this is a read-only, idempotent, non-destructive tool. The description adds meaningful behavioral context by explaining the data source size, shrinkage toward the average, ranking by the low end of the interval, and precise meanings of the 'proven' and 'promising' tiers.

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

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

The description is two dense but efficient sentences, front-loading the resource and then adding methodology and tier definitions. Every sentence contributes directly to understanding the output and confidence labels.

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 analytics tool with a fully described schema and safety annotations, the definition provides enough context to call it correctly. It could be stronger by clarifying how this tool differs from related siblings, but the core return concept and tier semantics are covered.

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 the baseline is 3. The description goes beyond the schema by defining the confidence tiers 'proven' and 'promising', which adds real semantic meaning to the tier parameter beyond its enum values.

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 clearly states the resource: reply rates by country × buyer type from real export emails, ranked by the lower bound of a 90% interval. It is specific about the data and methodology, but it does not explicitly differentiate itself from potentially related siblings such as reply_pace or outreach_playbook.

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 intended use is implied by the title and description: identifying country × buyer type segments with high reply likelihood. However, there is no explicit when-to-use guidance, no exclusions, and no reference to alternative sibling tools that might be more appropriate for adjacent questions.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description doesn't need to. It does add useful context: the output carries an estimated data cost, per-call prices for treg.to endpoints, and an official source link for compliance — but it says nothing about whether calling this tool itself consumes quota, how large the response is, or what happens for unsupported countries.

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

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

It is front-loaded with the deliverable type, which is good, but the rest is one long run-on sentence packing seven or eight content categories plus a cost note. The inventory could be trimmed or restructured without losing information an agent needs to select the tool.

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

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

For a five-parameter, one-required read-only tool with a fully documented schema and no output schema, the description is complete enough about what comes back. The residual gap is selection context — when this beats gtm_plan or country_brief — rather than invocation context.

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

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

Schema description coverage is 100% and the parameter descriptions are unusually rich (enum values, trait vocabulary, HS4 examples), so the schema does the heavy lifting. The tool description adds no parameter-level meaning beyond what is already documented — it doesn't explain how motion interacts with traits or what 'all' returns for consumer goods.

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 deliverable ('GTM engineering plan for one country') and enumerates its contents precisely enough that an agent knows what it gets back. It does not, however, distinguish it from the sibling gtm_plan or country_brief, which appear to overlap heavily — no sentence says why to pick this one.

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

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

Usage is only implied by the content inventory and by the note that 'all' adapts to item type (industrial goods get b2b/trade/search only). There is no explicit when-to-use guidance, no exclusions, and no named alternative despite several plausibly overlapping 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 and the description correctly does not restate it. It adds useful behavioral context by inventorying the returned sections and flagging that US state data is country-conditional. It says nothing about size, pagination, latency, or how sparse the response is when no item is supplied.

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 opens with the scope statement and then lists the sections, and every listed item is informative rather than filler. It is a long, comma-heavy run-on that takes effort to parse, which keeps it off a 5.

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

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

With no output schema, the description carries the burden of telling the agent what comes back, and the section inventory does that reasonably well, including the country-conditional nuance. Gaps remain: it does not indicate the brief's behavior when the optional item/traits/description are omitted, which matters for a tool whose params are mostly optional.

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 the schema already explains item, traits, country and description in detail; the baseline of 3 applies. The description contributes nothing parameter-specific — it never mentions country, item, traits or description, nor how omitting item changes the brief.

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 resource ('everything TradeGraph knows about one country') and enumerates the concrete payload sections: reply rate, buyer types, import size/growth/Korea share, supplier mix, industry reply rates, US states, channels and disclosure rules. An agent can tell this is the broad single-country profile tool rather than a narrow lookup. It stops short of naming a sibling (e.g. market_scan, buyer_targets) to contrast against, which keeps it from a 5.

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

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

Usage is only implied: 'everything TradeGraph knows about one country' suggests a broad orientation call before drilling into narrower tools, and '(for the US)' hints at conditional coverage. Nothing states when to prefer this over market_scan, export_rank, buyer_targets or reply_pace, and there are no preconditions or exclusions.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds genuine context beyond them: the data source (UN Comtrade) and recency (latest year), plus what the result contains. It does not describe result size, units, or ranking length, so it stops short of full behavioral disclosure.

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

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

One dense sentence with no filler, and the most discriminating detail (world ranking) comes first. It is a noun phrase without an explicit verb, which slightly weakens front-loading of the action, but nothing is wasted.

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

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

With no output schema and a single fully-documented parameter, the description carries most of the burden and does sketch the return content (exporter ranking, Korea rank/value, top markets). It could say more about how many exporters are returned or the response shape, but it is sufficient for a correct call.

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

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

Schema coverage is 100% and the single `item` parameter is richly documented with HS4 codes and name examples. The description only restates 'a product' and adds no format, validation, or fallback detail beyond the schema. Baseline 3 is appropriate when the schema does all the work.

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

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

The description names a specific resource and scope: world exporters of a product from UN Comtrade, plus Korea's rank, value, and top markets. An agent can tell it returns a ranking view rather than a general market scan. It does not name or contrast any sibling (market_scan, country_brief, find_item), so differentiation is left implicit.

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

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

There is no explicit when-to-use or when-not guidance and no named alternative among the many sibling tools. Usage is only implied by the scope: product-level export landscape centered on Korea. An agent must infer the routing decision itself.

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

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

Annotations already declare readOnly/idempotent/closed-world, so the description focuses on added context: 10-language input support, coverage breadth, disambiguation rules ('ginseng cream' is 3304, not 1211), and conditional return fields (hs_by_form). It does not describe fallback behavior when no item matches, which is the main remaining gap.

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

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

The core action and scope are front-loaded in the first sentence, with disambiguation and return-shape caveats following. The parenthetical example lists (kimchi 2005, shampoo 3305, ginseng roots 1211…) are slightly overstuffed for a single paragraph but each illustrates a mapping rule.

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 one parameter and no output schema, the description carries the burden of explaining return values, and it does so for the conditional hs_by_form cases. Coverage limits and disambiguation rules are covered; the unmatched-input path and general return shape are not.

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

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

Schema coverage is 100%, so baseline is 3; the description earns above that by clarifying the query accepts any of 10 languages and raw HS digits (e.g. '3304'), plus concrete examples of what a valid query looks like. It adds real interpretive value over 'Product name, alias or HS digits.'

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: resolve a product description to one of 35 HS4 items or the usual HS4 code of ~60 other consumer products. It names the downstream consumers (gtm_plan, market_scan) and the domain, so an agent can distinguish it from every sibling in the list.

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 before other tools when unsure of the HS code" gives explicit sequencing and a clear conditional trigger. The 'when unsure' framing implies the inverse case, but there is no explicit statement of when to skip it or what to do on no-match.

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 safety (readOnlyHint, idempotentHint, destructiveHint=false), but the description still adds real substance: output size of 40,000-80,000 characters, the cost of detail=brief and what it omits, and the gated/banned-market behavior (human-derived ingredient bans that no approval opens). It could say more about latency or failure modes for an international lookup, but the added context is well beyond the annotations.

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

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

The purpose is front-loaded, but the opening sentence is a single sprawling clause that enumerates a dozen output fields in one breath and runs most of the description's length. The reader must parse semicolons within parentheses to find what they need; this is dense rather than concise, and the structure does not help scanning.

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 tool with 9 parameters, no output schema, and this much downstream structure, the description covers return size, gating semantics, defaults, auth requirements, and sibling delegation. An agent can call it and interpret the result without consulting anything else.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns a bump by tying parameters to outcomes — omitting country lets 'the data pick the market', exclude feeds next_markets, traits/description trigger blind_spots, product_local selects Japanese drafts. Most of this restates the schema, but the parameter-to-output relationships add usable meaning.

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 first words 'START HERE. One call returns the export go-to-market plan for a product' give a specific verb and resource, followed by an enumeration of returned artifacts (markets, buyer types, follow-ups, channels, compliance flags, tariffs, drafts). Sibling tools like channel_plan, reply_pace, blind_spots, and save_plan are named with their distinct roles, so an agent can differentiate this from them 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?

Explicit entry-point guidance ('START HERE'), explicit when-to-use-detail=brief ('for a first answer or to compare markets') versus full ('when picking drafts in the weekly routine'), and explicit delegation rules ('call channel_plan for endpoint ids, prices and request bodies'; save_plan for persisting). Prerequisites (signed in at /mcp/account, free, read-only) are stated.

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

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

Annotations already carry the safety profile, and 'Free, read-only' merely restates readOnlyHint, which earns no credit. The valuable addition is disclosing that the tool returns prompts and a plan (7-image gallery, edit-from-packshot prompts, ad sizes, claims rules, estimated cost) rather than generated images — a non-obvious behavioral fact for a tool whose name suggests image creation.

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

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

It is front-loaded with the core action, but the rest is one run-on sentence with nested parentheses and ellipsis lists that is hard to scan. The trailing 'Free, read-only' duplicates structured annotations and does not earn its place.

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

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

With no output schema, the enumeration of deliverables is what makes this tool callable with correct expectations, and it covers composition, platform rules and cost. Enough is present; only the prompt/target-model handoff for downstream generation is left implicit.

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 the baseline applies and the schema already defines item, country, product, variants and marketplace. The description adds nothing about how the two product-ish parameters (item vs product) interact or what marketplace selection changes — the one real ambiguity left unaddressed.

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?

Opens with a specific verb and scope ('Plan the product image set for one market') and enumerates the concrete deliverables, so an agent can tell this apart from video_studio or channel_plan. It stops short of naming a sibling or state of work it is not, which keeps it at 4 rather than 5.

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

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

The trigger condition is implied by 'for one market' and the required country parameter, and 'Free, read-only' signals a safe planning call. There is no explicit when-to-use/when-not guidance and no routing to alternatives such as video_studio for motion assets, so 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 declare readOnly/idempotent/openWorld, but the description adds substantive context beyond them: the catalog size (3,800+ endpoints, 110 providers), what is returned, the two execution paths, that calls are charged to prepaid credits, and that no money is spent without an account. This is real behavioral disclosure about cost and auth that the annotations cannot convey.

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 search purpose and examples are front-loaded, and the sentence about execution paths is useful for an agent deciding what to do after the search. The inclusion of the MCP URL and CLI syntax is slightly more operational detail than a search tool strictly needs, but it is compact and not padded.

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

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

For a two-parameter, read-only discovery tool with no output schema, the description covers what can be searched, what comes back (ids, providers, per-call prices), and how to proceed after the search. Only the exact response shape and pagination/limit behavior are left implicit, which is minor here.

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

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

Schema coverage is 100%, so the baseline is 3, but the description's worked examples clarify that `job` is a natural-language goal in English or Korean rather than a keyword or endpoint id, which adds genuine meaning beyond the schema's short one-liner. The `limit` parameter is left entirely to the schema, which is acceptable given full coverage.

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

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

The description names a specific verb and resource — searching the treg.to catalog of live-data endpoints — and backs it with concrete job examples ('find TikTok beauty creators', 'Amazon best sellers'). It also distinguishes itself from the other tools by noting it returns endpoint ids/providers/prices rather than performing the job itself.

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

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

It clearly says when to use it: to find an endpoint that does a job, with examples of the kind of job phrasing expected. It then routes the agent onward to live_call, the treg MCP server, or the CLI depending on account state, which is explicit usage guidance. It doesn't state exclusions (e.g. when the sibling tools like market_scan or find_item are the better choice), so it stops short of a 5.

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

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

Beyond the read-only annotations, the description discloses real analytical behavior: what 'pick' means (Pareto frontier: no other market both bigger and better-replying), that Korea domestic and sanctioned markets are excluded from picks, that regional_hub markets overstate local demand, and the reply_scope='none' case where an industry has no emails and is therefore unranked. These are exactly the caveats an agent needs to interpret results without misreading 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?

The ranking basis is front-loaded, which is good, but the text is three long, jargon-heavy sentences dense with nested parentheticals ('reply_scope: industry = compared with...', 'regional_hub flags...'), making it slower to parse than necessary. Every clause carries information, but the packaging could be tightened into a short lead plus caveat list.

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

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

With no output schema, the description carries the burden of explaining return fields, and it does so for the non-obvious ones (pick, regional_hub, reply_scope, exclusions). It stops short of describing the overall result shape or ordering guarantees, but an agent can call it and interpret the output correctly.

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

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

Schema coverage is 100% and both parameters (item, limit) are fully documented with examples and bounds, so the description need not add parameter detail. The one concept it expands, reply_scope, is not actually a declared input parameter, so it functions as output semantics rather than parameter semantics; baseline 3 applies.

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

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

The opening clause states the resource and the ranking basis ('Import markets for a product ranked by size, with 3-year growth, Korea's share and the reply rate'), which tells an agent exactly what comes back. It does not name or contrast with the closest siblings (market_scan, export_rank, buyer_targets), so differentiation relies on the agent already knowing those tools.

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

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

There is no statement of when to use this tool rather than market_scan or export_rank, nor any prerequisite or exclusion guidance for the agent's decision. Usage is only inferable from the title 'Where to sell a product' and the ranked-markets content.

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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: the tool is free, uses live UN Comtrade data, and the first call for a code takes a few seconds, which helps set latency expectations.

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 dense but front-loaded paragraph with no filler. Every clause contributes: scope, data source, output components, alternative tool, cost, safety, and latency.

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 adequately explains the returned content: imports by country, latest complete year, 3-year growth, Korea's exports, reply rates, and Pareto picks. Combined with rich annotations and full schema parameter coverage, an agent has enough information to call the tool correctly.

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

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

Schema description coverage is 100%, and the schema already documents the hs code format with examples and the limit parameter with its bounds and default. The description reinforces that any 4-digit HS code is accepted but adds no extra syntax or semantics beyond the schema, so the baseline of 3 applies.

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

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

The description states a specific operation and resource: live UN Comtrade import markets by country for any 4-digit HS code, enriched with TradeGraph reply rates and Pareto picks. It also scopes the tool to products outside TradeGraph's 35 items and distinguishes it from gtm_plan, so an agent can tell what this tool returns.

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

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

It gives a clear usage condition ('For products outside TradeGraph's 35 items') and names gtm_plan as the alternative for a full plan using the same HS code. It does not explicitly say what to use for products inside TradeGraph's 35 items or clarify overlap with sibling tools such as market_picks, so it falls short of fully explicit 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?

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds meaningful context beyond that: the data is empirical (measured from 2.2M real export emails) and the 'per 10,000 emails' normalization unit, which tells the agent how to interpret the numbers. It says nothing about freshness, sample segmentation, or whether figures are sliced by industry/step, leaving some interpretive gaps.

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 provenance and payload are front-loaded in the first clause, which is good. However, the body is a single long run-on sentence that strings six-plus metrics together with parentheticals, making it harder to scan than a short bulleted breakdown would be.

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

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

With no output schema, the description carries the burden of describing returns, and it does enumerate the metric families an agent will receive (per-step reply rates, recommended email count and cadence, reply timing, reply intent categories, funnel). It is complete enough to call correctly, though it omits the shape/grouping of the response (e.g., whether results are broken out by step or segment).

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

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

The tool takes zero parameters, so the baseline of 4 applies. The only 'parameter-like' detail mentioned, follow_up_after_days, is described as a returned metric rather than an input, which is consistent with the empty schema.

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

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

The description names the resource precisely (benchmark email metrics derived from 2.2M export emails) and enumerates the specific metrics returned: replies per 10,000 at each step, recommended email count, follow_up_after_days, reply timing, reply intents, and funnel. It does not differentiate itself from the sibling reply_pace, which appears to cover overlapping territory (reply timing), so an agent can understand what it does but not how it differs from that neighbor.

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 closing sentence gives a clear use case: 'Use to set a sequence's length and timing,' which tells the agent the decision this data supports. There is no explicit exclusion or named alternative (e.g., reply_pace), 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?

Beyond the readOnly/idempotent/non-destructive annotations, it discloses the defaulting logic (checked duty rates for US Section 301, JP RCEP, MX general tariff, otherwise 0% with a lookup note), the ECB reference-rate basis with as_of, and that every assumption is returned and overridable. That matters, though a good share of it is restated from the parameter schema rather than adding new behavioral context about e.g. latency or failure modes.

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

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

Front-loaded with the core transformation in sentence one, which is good. But the cross_border parenthetical is a single enormous clause packing the Japan de-minimis rule, exclusions, excise, and the 1 Apr 2028 change into one sentence, hurting scannability; that channel detail is already carried by the channel parameter 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 21 parameters, no output schema and one required field, the description does the necessary work: it names key return payloads (compare, compare_basis, fob_at_targets, local, as_of, assumptions) and explains which inputs are mutually exclusive. An agent can call it correctly without further context.

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

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

Schema coverage is 100%, so the baseline is 3; the description still earns a bump by giving domain meaning the schema alone does not: what each channel means commercially, how compare 'auto' picks markets, and why b2b channels stop at the pre-VAT end-user price. Still, duty and margin semantics largely duplicate the per-parameter descriptions.

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 opening sentence states a precise bidirectional verb+resource: FOB to landed/importer/shelf price, or target shelf price back to the highest FOB. No sibling tool (channel_plan, gtm_plan, market_scan) does pricing math, so the role is unmistakable.

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?

Channel selection is spelled out with concrete routing rules and conditions (cross_border is Japan-only; b2b is the default for equipment, parts and medical devices; compare is 'not for cross_border'; target_shelf_local replaces target_shelf_usd). It never routes against sibling tools such as channel_plan or gtm_plan, so upstream/downstream positioning 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?

The annotations already declare read-only, idempotent, non-destructive, closed-world behavior, but the description adds real context beyond them: status meanings, decision thresholds at 10 replies, warm-share rules, statistical backing from 2.2M emails, and the account_note behavior when signed in. The disclosure is rich, though it is delivered in a dense and sometimes confusing run-on form.

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 sprawling paragraph with semicolon-chained clauses and nested return-value enumerations. It is front-loaded with the purpose, but the size and density make it hard for an agent to parse quickly, and many details duplicate the schema.

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?

Because there is no output schema and the tool returns many status values and advice fields, the description must explain return semantics, and it does so thoroughly. It covers status thresholds, decision logic, warm-note behavior, and account-note additions, leaving little functionally missing even if the presentation is poor.

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

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

Schema coverage is 100%, so the schema already documents all nine parameters. The description adds some meaning, such as 'each buyer once, first emails only,' 'a no counts,' and how exclude is used, but much of this repeats the schema rather than extending it.

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 opening line states a specific computation for a specific resource: a weekly pace check for one market based on sent/replies. It distinguishes itself from nearby tools by naming find_buyers_type, email_draft, gtm_plan, and my_progress, though the surrounding sprawl makes the core purpose less crisp than it could be.

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

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

It explicitly says to call this first in the weekly routine and act on it before anything else, and it points to my_progress as the alternative for a saved buyer list. It does not state exclusions or prerequisites in a clean when-not form, but the sequencing guidance is unusually explicit.

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, closed-world, and safe; the description adds genuinely non-redundant behavior: it costs nothing, it never mutates the packshot ('the pack never changes'), the output includes estimated cost, and generation is deferred to the user's treg token. It omits any statement about determinism of preset selection or plan size beyond variants, which keeps it at 4.

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 core scope is front-loaded, but the first sentence is a single ~130-word run-on that packs presets, prompts, request bodies, model tiers, hook variants, platform specs, compliance rules, and cost into one breath. It is information-dense but would be far easier to parse as structured clauses.

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

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

With no output schema, the description carries the burden of describing the return value and does so thoroughly (shot list, keyframe and image-to-video prompts, request bodies, hook variants, platform spec, cost). The only gaps are how presets interact when multiple are requested and whether 'auto' can be overridden per platform.

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

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

Schema coverage is 100% and every parameter is already documented, including the tier-to-model mapping and preset enum. The description restates that same mapping ('draft Seedance 1 Lite, standard Hailuo 2.3, premium Veo 3.1 Fast') rather than adding new semantics, so the baseline 3 applies.

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

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

States a specific verb and resource ('Plan AI product videos for one market and platform') plus a recognizable style reference and an explicit inventory of what it produces. It is clearly distinct from the sibling image_studio and from analytical tools like channel_plan.

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 closing line 'Free, read-only — generation runs on the user's treg token' makes the planning-vs-generation boundary explicit, which tells an agent when this tool stops and actual rendering begins. It does not name a sibling alternative or state exclusions (e.g., multi-market planning), so it stops short of a 5.

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