One1 Trademark Risk Check

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

With no annotations, the description carries the full burden and does so well: it discloses the static-snapshot origin, the per-country backend-first/fallback-static behaviour, and the semantics of key outputs (clearance_ok, warning, scope, count vs conflict_count, visual_similarity, TRO/enforcement). It omits auth/rate-limit/performance characteristics, keeping it out of the top band.

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 body is a dense wall of text that largely restates the input schema field-for-field, so a large fraction of the tokens do no additional work. Ordering mixes parameter rules, output-field caveats, and unrelated historical-interface notes without clear 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 no annotations, the description supplies the missing output-field semantics (clearance_ok, warning, scope, count, has_conflicts, conflict_count, visual_similarity) and provenance caveats, which is substantial. It still leaves the operator without guidance on permissions or result-size/pagination behaviour.

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 description text is essentially identical to the parameter's schema description, so it adds no meaning the schema does not already carry. The rules (trim/uppercase, UK/EU/WO codes, no multi-country lists, supported code list) are all duplicated verbatim in the schema. Baseline 3.

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 specific verb+resource: '查询 One1 已覆盖国家/地区的数据范围和覆盖限制' (query One1's covered countries' data scope and coverage limits). It also implicitly differentiates from siblings by noting that number/owner tools only query local sources and that graphical interfaces behave differently, though it never names a sibling tool directly.

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 call pattern ('先调用 coverage_info(country="") 获取覆盖清单，再以目标代码查询各国覆盖') and explicit exclusions about what the result does NOT prove ('不证明每个工具均支持该辖区', '无命中不等于可注册或不侵权'). It does not, however, name an alternative tool to use instead for any given case.

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?

No annotations exist, so the description carries the full burden. It discloses coverage limitations, static snapshot/fallback behavior, warning/scope/clearance_ok semantics, count meaning, visual_similarity caveats, TRO/enforcement caveats, and official-source limits extensively.

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 description is a sprawling wall of caveats with duplicated country-code details from the schema and repeated legal warnings. Much information is useful, but it is not appropriately sized or tightly structured.

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 no-annotation, no-output-schema, high-complexity legal search tool, it supplies the return shape, country coverage routing, coverage_info prerequisite, and critical caveats. An agent has enough context to invoke it correctly and interpret results cautiously.

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

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

Schema description coverage is low at 25%, so the description has to compensate. It explains image_url (publicly accessible PNG/JPG), nice_class optionality, limit default, and country code rules/coverage; it omits limits/bounds for limit and nice_class format examples.

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: query graphic trademark data by target country and return visually similar candidates. The use case ('卖家查自家 Logo/图案是否撞已注册图形商标') further distinguishes it from sibling tools like trademark_text_search.

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

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

Gives clear context (seller logo conflict checks) and operational guidance: call coverage_info first, use single country codes, and treat no-hit/clearance_ok cautiously. It differentiates from serial/owner tools and text search only indirectly rather than naming a sibling alternative for text-based lookups, so not a full 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?

With no annotations, the description carries the full burden and discloses many behavioral traits: country codes are largely ignored, only US is served, non-US raises errors, and it must not claim to have scanned the target country. It also explains country normalization, routing, coverage caveats, count semantics, TRO/enforcement signals, and source-specific limitations.

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 extremely long and rambling, with many sentences about unrelated tools, coverage behavior, and general disclaimers that do not help invoke listing_scan. The purpose is front-loaded, but the remainder is poorly structured and repetitive, so most sentences do not earn their 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?

Given no annotations, no output schema, and low schema coverage, the description does provide substantial behavioral context, return shape, and caveats. However, it is bloated and omits details such as nice_class format and risk-level thresholds, so it is complete enough but not ideal.

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

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

Schema coverage is only 33%, so the description must compensate; it defines text as a listing title or copy, nice_class as an optional Nice class number, and repeats extensive country semantics. The country detail is already present in the schema, so the description adds little there, but it adequately covers the undocumented text and nice_class parameters.

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 a specific verb and resource: scanning a listing for trademark risk words, and it specifies the use case of seller pre-listing self-check of an entire listing title. It does not name or differentiate from sibling tools such as trademark_text_search, so it falls just 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?

It gives clear context for use (seller product-listing self-check) and an explicit when-not: the backend ignores country and only US works, with non-US requests erroring. It also instructs calling coverage_info first, but it does not point to alternative tools for non-US scenarios, so not 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?

With no annotations at all, the description carries the full burden and does so: it discloses the return shape, single-country-preferred-backend with static-snapshot fallback, the presence of warning/scope/clearance_ok signals, count semantics (return quantity, not conflict count), that visual_similarity is not infringement probability, and data-staleness/coverage limits. These are non-obvious traits an agent must know before trusting output.

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 in the first line, but the body is a long undifferentiated wall of text that duplicates the schema's country description verbatim and imports large amounts of coverage_info-specific detail (routing partners, graphic library codes, coverage_status caveats) that do not help call this tool. Structure is poor relative to size.

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 or annotations, the description supplies the return shape {serial, found, result:{mark, legal_status, applicant, risk_level, ...}} and the caveats needed to interpret it. It is nearly sufficient, though the diffused organization means an agent must sift coverage-related material to find the lookup-relevant parts.

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 50% because serial has no schema description, but the description compensates by defining serial as the number inside the target country's database and giving a concrete example ("78414956" is US-only). Country semantics are restated from the schema rather than adding new 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?

States a specific verb+resource: query a covered country's trademark database by exact serial number. It also differentiates capability from sibling tools ("编号/权利人工具仅查本地源，能力与文本检索不同"), though it never names trademark_text_search or the owner tools directly, so the routing is inferable rather than explicit.

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 concrete trigger ("用于已知商标号(如收到侵权通知里的号)时直接查该标") and an explicit prerequisite workflow ("先调用 coverage_info(country="") 获取覆盖清单"). It stops short of naming which sibling to use instead when only a name/owner is known.

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?

With no annotations, the description carries the full burden and does substantial work: it discloses the static-snapshot source with single-country priority backend and static fallback, that clearance_ok=false blocks registrability conclusions, that count is a return count not a conflict count, that visual_similarity is not infringement probability, and that TRO/enforcement are in-library signals needing source/time verification. It omits auth/permission and rate-limit behavior, which keeps it from a 5.

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

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

The purpose and usage lines are front-loaded well, but the body is bloated and repetitive: the entire country-code paragraph is duplicated verbatim in the schema, and large chunks about graphic interfaces, USPAT design codes, and ARIPO/OAPI codes are irrelevant to an owner-profile tool. Many sentences do not earn their place in this definition.

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?

Despite having no output schema, the description enumerates the return shape (owner, is_enforcer, enforcement{level,note,src}, total_marks, live_marks, top_classes, tro_marks, sample_marks, risk_hint) and explains how to interpret it, plus the coverage_info prerequisite. It is complete enough for correct invocation, with the main residual gap being the undefined boundary against sibling owner-search tools.

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 50%: 'country' is heavily documented in the schema itself (and the description largely duplicates it verbatim), while 'owner' has no schema description and is only clarified here ('权利人或品牌名,如 "Nike" 或 "YETI"'). The description adds an example and normalization notes for owner but contributes little beyond the schema for country.

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 states a specific verb+resource: query One1-covered trademark data by target country and aggregate the owner's portfolio plus in-library enforcement signals. It also hints at differentiation from siblings ('编号/权利人工具仅查本地源，能力与文本检索不同'), though it never names trademark_owner_search or trademark_text_search directly, so an agent must infer the boundary.

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 use case (sellers judging whether a brand aggressively enforces via Schedule A/TRO and should be avoided) and an explicit prerequisite sequencing step ('先调用 coverage_info(country="") 获取覆盖清单'). It also warns when NOT to over-read results ('无命中不等于可注册或不侵权'), but does not compare against the sibling owner/text search tools.

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

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

With no annotations, the description carries the full burden and does so extensively: it explains static-snapshot vs per-country backend with fallback, the meaning of warning/scope/clearance_ok, that count is a result count (neighbor count for approximate text) rather than a conflict count, that visual_similarity is not an infringement probability, and that TRO/enforcement are in-library signals needing source verification. It also warns that no hits do not imply registrability or non-infringement.

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 and return shape are front-loaded, which is good, but the country block is enormous and repeats essentially verbatim what the schema already documents, and the caveat section is a dense run-on. Several sentences re-explain coverage limitations multiple times, so signal-to-noise suffers.

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, but the description supplies the return shape ({owner, count, results:[{mark, nice_class, legal_status, risk_level, tro_alert?}]}) and the major data-freshness and interpretation caveats. Combined with the coverage_info-first workflow, an agent has enough to call and interpret results, though field-level semantics for the returned objects remain thin.

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

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

Schema coverage is only 25% (country alone), so the description must compensate, and it does: owner is defined with an example ("Nike, Inc."), live_only is explained as live-only filtering with default False, and limit's default 20 is stated. The country text largely duplicates the schema description rather than adding new meaning, so it is not a full 5.

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: query trademark data for a target country and retrieve records under an owner/applicant name. It also differentiates somewhat from siblings by noting that number/owner tools only query the local source while text search differs. That differentiation is present but buried mid-paragraph rather than front-loaded.

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 use cases (competitor owner profiling, mapping a company's trademark portfolio, spotting frequent enforcers) and prescribes a workflow: call coverage_info first, then query per-country. No explicit when-not or comparison against siblings like trademark_owner_profile is stated, so it stops 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?

With no annotations, the description carries the full burden and does disclose substantial behavior: count is neighbor count bounded by limit, not conflict count; has_conflicts/conflict_count are the real signal; coverage.clearance_ok=false invalidates a 'no conflict' conclusion; data comes from a static snapshot with per-country scope/recency differences and no cutoff-date field. It omits auth/permission and read-only/rate-limit traits, which keeps it below 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?

Front-loaded enough with clear ⚠️ markers, but the reading-rule caveat about count vs. conflict_count is stated twice, and a large block of country-routing lore (BX/DE/ES/IT/TR, USPAT, ARIPO/OAPI) duplicates the schema's country description and is tangential. Noticeably bloated for the information delivered.

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 or annotations exist, so the description supplies a return shape ({query, conflict_count, has_conflicts, count, results, coverage}) and extensive caveats about interpreting coverage and counts. For a 5-parameter search tool this is nearly complete; the remaining gap is the absence of auth/permission and rate-limit 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 only 20% (just country), so the description must compensate and largely does: query is the brand/trademark term, nice_class is the Nice classification with an effect on risk re-ranking, live_only limits to Live registrations (default False), and limit is the result count (default 10). It adds meaning beyond the schema defaults, though examples are thin for nice_class format beyond '025'.

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+resource (query One1's covered trademark data by target country, retrieve phonetic/visual/meaning-similarity candidates for a brand name) and frames the use case (sellers checking for conflict before naming a product). It also distinguishes itself from siblings by noting that serial-number and owner tools query only local sources and that the graphic interface returns different candidates.

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 context (use before naming a brand to check conflict) and a prerequisite workflow (call coverage_info first, then query per country). It does not explicitly state when to prefer graphic_trademark_search or the owner/serial tools instead, so exclusions are only partially covered.

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