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

With no annotations provided, the description carries the burden of behavioral disclosure. It adds meaningful behavioral context by promising a 'full GLEIF record' and enumerating the group-structure fields returned. It does not discuss failure modes or data freshness, but for a simple get-by-identifier tool this is reasonably transparent.

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, information-dense sentence with no filler. The main purpose is front-loaded, and the group-structure detail is appended efficiently. Every word adds value.

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

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

For a low-complexity tool with one required parameter, no output schema, and no annotations, the description is mostly complete: it states the input and the key contents of the output. It could be even more complete by mentioning whether invalid LEIs return an error or null, but this is not critical for selecting and invoking the tool.

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

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

The input schema fully documents the single 'lei' parameter with an example and format, giving 100% schema coverage. The description does not add any parameter-level semantics beyond what the schema already provides, so the baseline score 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 clearly identifies the resource (a LEI), the action (returning the full GLEIF record), and the specific scope (including direct parent, ultimate parent, and subsidiaries). This is precise and naturally distinguishes the tool from search-oriented siblings like company_search or nl_company_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?

The description implies when to use the tool: when you have a LEI and need the full GLEIF record. However, it does not explicitly state when not to use it, nor does it compare itself to sibling tools such as company_search or eu_company_search, so the agent must infer the boundary from context.

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

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

With no annotations, the description carries the behavioral transparency burden and does so well: it discloses the source (GLEIF), the coverage scope (LEI holders only), and the returned data categories. It does not mention matching behavior or rate limits, but the most decision-relevant limitation is clearly 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 focused sentences with no filler: purpose and returned fields, use case, and critical limitation. Each sentence earns its place without repeating schema content.

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 3-parameter search tool with no annotations and no output schema, this is largely complete: it names the fields returned and the main exclusion. It could add partial-match behavior or the possibility of multiple matches, but those are inferable from the schema and the search semantics.

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 description does not need to re-explain parameters. It reinforces that `name` is the search key, but it adds no parameter-level detail 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?

Clearly states the verb (Find), the resource (a company by name in GLEIF), and the data fields returned, including legal form, status, address, national registration number, and LEI. The LEI-scope caveat also helps distinguish it from sibling company-registry 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?

Provides a concrete use case (identifying a trademark holder) and an explicit limitation (only entities that hold a LEI, many SMEs excluded), so an agent knows when not to rely on it. It does not name a specific sibling tool as a fallback, which would make routing fully 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?

No annotations are provided, so the description carries the burden. It accurately conveys a read-only lookup action and clarifies supported countries and identifier types. However, it does not describe return behavior, error cases, or whether both Polish number formats are accepted interchangeably.

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

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

Two sentences with no filler, and the primary action is front-loaded. The only minor flaw is the slightly ambiguous pronoun 'it' in the second sentence, but the meaning is recoverable from context.

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 lookup, the description provides enough context to invoke the tool correctly, including country-specific number types and a routing hint for Poland. It omits return-format details, but there is no output schema and the core usage is well 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 coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema by explaining that 'number' means ICO in Czechia and NIP/REGON in Poland, and by giving concrete ISO examples 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?

States a specific verb ('Look a company up') and resource ('national registration number'), and clarifies the exact number types per country (ICO, NIP, REGON). It also differentiates from name-based search by noting that for Poland this is the only route.

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 for when to use the tool: when a national registration number is available, and specifically for Poland since name search is not an option. It does not explicitly name the alternative tool for name-based lookup, but the guidance is strong enough for an agent to route correctly.

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 burden and provides useful behavioral facts: the service is free, requires no API key, and a single call can span all seven registers. But it does not disclose result shape, ordering, rate limits, or error behavior, leaving meaningful gaps for an agent invoking without an output schema.

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 short sentences deliver the core action, target regions, the required parameter, cost/auth characteristics, and the key optional-country behavior. There is no filler or repetition of schema details.

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

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

For a low-complexity read-only search tool with fully documented parameters, this description covers the essential selection and invocation context: target countries, name matching, optional country, and auth requirements. The lack of an output schema and explicit sibling differentiation prevents it from being fully complete, but those are minor gaps 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% and the schema already describes name, country, and max_results clearly. The description mainly restates that lookup is by name and that country can be omitted, so it adds little beyond the structured parameter definitions.

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 opens with a specific verb and object — 'Search the national company registers' — and immediately scopes it to seven named countries and by-name lookup. This clearly distinguishes it from the sibling eu_company_by_number and narrower nl_company_search 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?

It gives clear context: use this when searching company registers by name in the listed countries, and explicitly explains that omitting country searches all seven. It does not, however, name alternatives or state when not to use it, 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 behavioral disclosure burden. It discloses the tool's domain and its interpretive role. Since this is a zero-parameter read-only reference, there are no side effects or auth requirements to document. It does not state the output shape, but the content categories are described.

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

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

Two sentences with no filler. The primary content is front-loaded and the usage warning 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 zero-parameter reference tool, the description covers the key information: what it lists and why it matters. It lacks an explicit statement of return/table format, but the output is intuitive and the usage guidance is 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?

The tool has no parameters, so the baseline of 4 applies. The description adds meaning to what the tool returns rather than parameter syntax; nothing else is needed here.

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 defines the tool's content: it lists countries with free registers, their identifiers, and countries without one, including reasons. This distinguishes it from the search-oriented sibling tools, though it lacks a direct verb phrase and does not explicitly name alternatives.

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

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

The final sentence gives explicit context: consult this tool before interpreting an empty result as proof of nonexistence. This is strong when-to-use guidance, but the description does not explicitly compare against sibling tools.

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

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

With no annotations, the description carries full behavioral disclosure burden. It reveals the paid nature ('PAID') and lists the returned profile contents, implying a safe read-only lookup. It does not mention error behavior or output format, but for a non-mutating data fetch the core behavior is reasonably transparent.

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 pack the core function, the key field for trademark work, and the cost flag with no waste. The most important information is front-loaded.

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 read-only lookup with two parameters and no output schema, the description covers the return content and the paid cost. It omits guidance on when to combine it with trademark tools, but that is more a usage-guidance gap than missing operational information.

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% because both parameters have descriptions. The tool description adds little beyond restating that the profile is keyed by KVK number and does not elaborate on establishment_number. 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 clearly indicates the tool returns a full Handelsregister profile for a KVK number and enumerates the fields (legal name, trade names, legal form, RSIN, addresses). This distinguishes it from sibling tools like nl_company_search or nl_company_tree.

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 'For trademark work the trade names are the most important field' provides an implied use case but does not explicitly guide selection among alternatives such as tm_search or nl_company_search. No exclusions or 'when not to use' guidance is provided.

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 has to carry the behavioral disclosure burden. It does disclose the paid/auth requirement and that a KVK number is returned, but it does not mention pagination, exact vs partial matching, no-result behavior, or whether this is a read-only search, so the behavioral profile is incomplete.

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 with no fluff: action and result first, GLEIF differentiator second, auth caveat third. Key information is front-loaded and every sentence earns its place.

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

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

For a 7-parameter tool with no annotations and no output schema, the description gives the core search intent and a credentials note, but leaves out practical invocation behavior such as pagination/result shape, handling of multiple or no matches, and how the kvk_number parameter fits. It is adequate for a first pass but not complete for fully reliable 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 coverage is moderate at 71%. The description adds plain-language meaning by listing trade name, city, postal code, and domain as search keys and clarifying the output. It doesn't mention that kvk_number can be used as an input, nor the paging/strict fields, though those are partially documented in 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 first sentence names a specific action ('Find'), a specific resource ('Dutch company in the Handelsregister'), the supported lookup keys (trade name, city, postal code, domain), and the expected output (KVK number). It also differentiates itself from GLEIF-based lookups by noting it covers SMEs that GLEIF misses.

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 provides clear usage context: use this when you need a KVK number for a Dutch SME via Handelsregister fields, and it calls out the paid credential prerequisite. The GLEIF sentence is a weak alternative signal, but it does not explicitly name sibling tools or state when not to use this one.

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

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

With no annotations provided, the description carries the full burden and does a decent job: it discloses that the output is a tree, that it extends beyond GLEIF/LEI coverage, that it contains personal data, and that it is a paid tool. It could add more detail about data sensitivity handling or response characteristics, but the key behavioral caveats are present.

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

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

Two sentences with no filler. The main purpose is front-loaded, followed by the coverage boundary and critical caveats about personal data and cost. Every clause contributes meaningful guidance for an agent.

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 one-parameter read-style tool with no output schema, the description explains the return shape (tree of parents, subsidiaries, UBO) and critical constraints (personal data, paid, LEI gap-filling). It is slightly incomplete around input format details and explicit sibling routing, but it is largely sufficient 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 0%, so the description should compensate, but it only restates that the input is a KVK number without specifying format, validation, or accepted variations. The single parameter name already communicates 'kvk_number', so the description adds little beyond what the schema shows.

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 identifies the tool's output: a group structure tree containing parents, subsidiaries, and UBOs for a KVK number. It is specific about the resource and content, but it does not explicitly differentiate from sibling tools like nl_company_profile or nl_company_search, though the tree/group-structure focus makes it fairly distinguishable.

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 provides a clear usage context: use this when GLEIF would stop due to missing LEI, since this tool continues the hierarchy. It names GLEIF as an alternative and gives an implied condition for selection, but it does not explicitly mention when-not-to-use relative to sibling tools or provide 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?

With no annotations, the description carries the full burden, and it discloses one important operational trait: the call is PAID. It also points to a free confirmation path. However, it does not mention failure behavior, response shape, or whether any restrictions apply, so transparency beyond purpose is limited.

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 fragments communicate purpose, workflow, and cost without redundancy. The key fact, VAT number from a KVK number, is front-loaded; every word 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?

The tool is simple enough that a one-line purpose plus cost and follow-up advice largely suffices. The absence of an output schema is mitigated because the description explicitly says the output is the VAT number; it could still use input-format examples or error behavior, but nothing critical blocks correct invocation.

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

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

The schema gives kvk_number with no description, so the name is self-explanatory and the description reinforces that it is a KVK number by saying 'VAT number for a KVK number.' It does not add a format, example, or transform guidance, leaving the agent to infer the expected value.

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 purpose: returning a VAT number for a given KVK number. It is clear enough to separate this from the listed company-search and EU lookup siblings, though it does not use a strong verb like 'retrieve' and does not explicitly contrast it with similar Dutch company 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?

It gives an explicit workflow: combine this tool's result with vat_check to confirm the name for free via EU VIES. It does not explicitly state when not to use it or name other alternatives, but the complementary relationship to vat_check is clear and actionable.

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 provided, the description carries the burden of explaining behavior. It is transparent about the output shape: 'a verdict plus three lists: identical live marks, identical expired marks, and live similar rights in your Nice classes.' It clearly implies a read-only check, though it does not disclose failure modes or edge-case 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?

Three sentences with no filler. The purpose is front-loaded, the return payload is described precisely, and the usage cue 'Start here' is minimal and effective. Every sentence earns its place.

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

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

There is no output schema, but the description covers the return structure with the verdict and the three lists. Parameter semantics are sufficiently covered by the 100% schema description. Minor omissions like error handling or what 'verdict' contains prevent a perfect score.

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 parameters are already documented. The description adds some context by tying 'name' to EU/Benelux registers and 'Nice classes' to the similarity lists, which is useful but not extensive. It stays at the baseline because it does not add significant new parameter-level detail 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 clearly identifies a specific operation: 'Clearance check on a name in the EU and Benelux registers' and specifies the output components. It doesn't explicitly compare against sibling tools, but 'Start here' positions it as the entry point, making its purpose distinctive enough.

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 'Start here' gives implied usage guidance: this is meant to be the initial clearance step. However, it does not name alternatives, state when not to use this tool, or explain how it relates to other search or watch 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 provided, the description carries the burden of disclosure. It does enumerate the main data categories returned (status, dates, validity, renewals, holder, oppositions, goods/services), which is useful, but it does not mention limitations such as data freshness, availability, or that the result is based on exact application number matching. There is no contradiction with annotations because none exist.

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, information-dense sentence that front-loads the core purpose ('Full EUIPO case file for an EU application number') before listing the included contents. Every phrase earns its place, and there is no redundant or vague 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 single-parameter lookup tool, the description lists the key return contents and the geographic scope, which is adequate for basic invocation. However, since there is no output schema, the description does not fully communicate the response structure or potential edge cases, and it leaves the relationship to sibling search/clearance tools 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 parameter is already well-documented with an example. The tool description reinforces that the parameter is an EU application number and that the tool is EU-only, but it adds no new formatting, validation, or domain details 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?

The description clearly states the resource (full EUIPO case file) and scope (EU marks only) and enumerates the contained data fields, making it easy to distinguish from siblings like tm_search or tm_clearance. However, the verb is implicit rather than explicit ('Full... case file' implies retrieval) and it does not name any sibling 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?

The intended use is implied: when you need a comprehensive EUIPO case file by application number, use this tool. Yet it provides no explicit guidance on when not to use it, no alternative tool names, and no boundary with tm_search or tm_clearance beyond the 'EU marks only' scope.

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 behavioral disclosure burden. It clearly indicates a read-only listing operation and specifies the return content (registers and codes), but it does not disclose output format, ordering, completeness guarantees, or any potential edge cases.

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 filler. Every word contributes meaning, and it is perfectly sized for a zero-parameter listing 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 simple, parameterless list tool, the description adequately states what the tool returns. However, it could be slightly more complete by hinting at how the register codes are intended to be used with sibling trademark tools, and it omits any output format details since there is no output schema.

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

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

There are zero parameters, so the schema already fully covers the input side. The description does not need to add parameter-level meaning, and the baseline of 4 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 uses a specific verb ('List') with a clear resource ('available trademark registers and their codes'). This makes its reference/list nature immediately distinct from sibling tools like tm_search, tm_detail, and tm_clearance, which are query-oriented.

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 explicit guidance is given about when to use this tool versus alternatives. It does not mention that it should be used before search/detail calls to obtain register codes, nor does it state any conditions 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?

There are no annotations, so the description carries the burden of behavioral disclosure. It adds useful behavioral context by explaining default jurisdictions and the effect of worldwide=true, but it does not disclose result format, pagination, limits, or whether the operation has any side effects beyond being a search.

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

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

Two sentences with no filler. The core purpose is front-loaded, and the key behavioral override is stated immediately after the default behavior, making the description easy to scan and digest.

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 basic call, the description is sufficient: it tells the agent what the tool searches, the defaults, and how to broaden to worldwide. But with no output schema and no explanation of max_results or nice_classes, an agent may still be unsure about expected responses or how to constrain results beyond the core query.

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 67%, so the description does not need to document everything, but it adds value beyond the schema by clarifying defaults for offices and live_only and by describing the effect of worldwide=true. However, max_results and nice_classes still lack semantic guidance in both the schema and the description.

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

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

The description uses a specific verb and resource ('Search trademarks in TMview') and states useful default scoping. However, it does not explicitly differentiate tm_search from the sibling tm_clearance, which is likely a related but distinct trademark search, so it misses full sibling differentiation.

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 gives clear context: it searches TMview, defaults to EU + Benelux and live rights, and supports a worldwide mode. It does not say when to prefer tm_search over tm_clearance or other sibling tools, so usage guidance is mostly implied rather than 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?

With no annotations, the description carries the full behavioral burden. It discloses that the tool performs a VIES lookup, returns official registration data, and confirms existence/active status. It does not mention potential external-service availability issues, invalid-number errors, or that this is a read-only operation, though the verb 'Verify' strongly implies it.

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, each earning its place. The core action and result are front-loaded, and the constraint is stated at the end without repetition or fluff.

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 output schema and no annotations, the description reasonably explains the return value (official name and address), the verification semantics, and the prerequisite input. It could go further on error cases or the optional country parameter, but the schema already covers the parameters and the core behavior is adequately specified.

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 adds the general constraint that a number is required and name search is impossible, but it does not add detail about the optional country parameter or the expected combined format beyond what the schema already states.

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 ('Verify') and resource ('EU VAT number against VIES'), and clearly says what is returned: officially registered name and address. It also differentiates from siblings by emphasizing this is a number-based verification, not a search tool.

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

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

Provides clear usage context: the tool requires a VAT number and cannot be used to search by name. It does not explicitly name sibling alternatives like eu_company_search, but the 'cannot be searched by name' constraint is a practical when-not that helps an agent select this tool.

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