dd

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

Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral context: it explains the threshold-based risk classification (1-9, 10-49, 50-199, 200+) and notes the compliance tier requirement, which is not covered by annotations. It does not contradict the read-only hint as 'detects' and 'counts' are read operations.

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 concise and front-loaded, starting with the tool's main function. Each sentence provides necessary detail: the definition, the thresholds, and the access requirement. There is no unnecessary repetition or 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 simple tool with one parameter, read-only annotations, and no output schema, the description is nearly complete. It explains the detection logic and thresholds, and includes the compliance tier requirement. It could be more explicit about the return format (e.g., whether it returns a count, a risk category, or both), which would be helpful given the lack of an 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?

Schema coverage for the single parameter (ico) is 100%, as the schema already describes it as 'Czech IČO 7-8 digits'. The description adds no additional information about the parameter itself, so it does not go beyond the schema. The baseline for high coverage is 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 description clearly states what the tool does: 'Detects shell-firm hotel patterns — counts how many companies share the same registered address.' This is a specific verb+resource with additional detail on the pattern. It differentiates itself from sibling detection tools by focusing on address crowding.

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 provides context on the tool's purpose and includes a threshold-based risk interpretation, which implies when it would be relevant. However, it does not explicitly state when to use this tool versus sibling tools like detect_nominee_director or detect_phoenix, nor does it mention any exclusions. The 'Compliance tier or higher' requirement is a usage constraint but not an explicit when/when-not guideline.

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 indicate readOnlyHint and openWorldHint. The description adds context about the return format (indicator breakdown with riskScore 0-100), the data source (ARES data alone), and an access tier requirement, going beyond the annotations without contradicting them.

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

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

The description is two sentences, front-loaded with the purpose, and includes all relevant details without any fluff. 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 single-parameter, read-only tool with no output schema, the description covers purpose, indicators, return summary, access tier, and alternative tool. It is complete and self-contained.

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 already fully describes the only parameter (ico) with format details. The description does not add parameter-specific information, so the baseline of 3 applies since schema coverage is 100%.

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 tool detects 'white horse' / nominee director patterns, enumerates the 3 surface indicators, and distinguishes itself from the deeper detect_nominee_director_rich variant. This leaves no ambiguity about the tool's scope.

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 explains when to use this tool ('Pro Compliance tier or higher') and directs users to detect_nominee_director_rich for deeper analysis with 8 indicators and additional data sources. This provides clear alternatives and 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?

The description goes well beyond the annotations (readOnlyHint, openWorldHint). It adds that the tool is computable from 'ARES + ISIR data alone', returns a 'PhoenixReport with riskScore 0-100', and requires a 'Pro Compliance tier'. These are important behavioral details not present in 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?

Three sentences, each with a distinct role: purpose/indicators, output/access, and alternative. No fluff or repetition. The information is front-loaded and every clause earns its place.

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

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

For a detection tool with several indicators and an output riskScore, the description covers the essential context: input (ICO), computation (3 indicators, data sources), output (PhoenixReport with riskScore), tiers, and a pointer to the richer version. It does not explain the interpretation of the riskScore or the structure of PhoenixReport, but given no output schema, this is a minor gap.

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 only parameter 'ico' is fully documented in the schema ('Czech IČO — 7 or 8 digits') with 100% coverage. The description does not add any additional meaning about the parameter itself, so the baseline of 3 applies as the schema carries the weight.

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 tool's purpose: 'Detect phoenix company pattern' and lists exactly what it computes (3 surface indicators). It also distinguishes itself from the sibling tool detect_phoenix_rich by specifying the limits of surface indicators vs deep indicators, making its role unambiguous.

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 guidance is provided: 'Pro Compliance tier or higher' states an access requirement, and 'For 4 additional deep indicators ... see detect_phoenix_rich' directly names the alternative and when to use it instead. This gives the agent clear decision criteria for tool selection.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, establishing a safe read-only snapshot. The description adds context about the report contents, such as per-member sanctions check and a transparent risk score with triggered red flags, but does not disclose API limitations, data sources, or response size. This adds moderate value 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?

Two sentences, front-loaded with the main purpose, then the report contents. Every word earns its place; no filler or repetition.

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 compensates by listing the main report sections, giving an agent a clear expectation of company facts, statutory body details, and risk score. It omits exact output formatting or risk score scale, but for moderate complexity, this is fairly complete.

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 provides excellent parameter descriptions: ico format ('7 or 8 digits') and depth enum ('basic = ARES + sanctions only; full = + ISIR insolvency + virtual-address probe'). The tool description adds no parameter information, so the schema carries the burden; 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?

Description opens with 'Generate a complete due-diligence report for a Czech IČO' – a specific verb, resource, and country scope. It enumerates report sections (company facts, statutory body, risk score), distinguishing it from sibling tools like get_eu_dd_report or get_risk_score.

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 clearly sets the context: use for Czech IČO to generate a complete due-diligence report. It does not explicitly mention when to use this over alternatives like get_risk_score or get_eu_dd_report, so it lacks exclusions, but the country and scope are well defined.

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 description goes beyond the readOnlyHint and openWorldHint annotations by detailing exactly what is returned (GLEIF entity data with status/address/registration number, sanctions screening against EU/OFAC lists), coverage notes, the SME limitation (important for expectations), and the tier requirement. This enriches behavioral understanding significantly.

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 compact and well-structured: purpose, input, output, coverage note, limitation, and access tier are each stated in one short sentence or clause. Every sentence adds essential information without redundancy.

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 report tool with no output schema, the description covers inputs, outputs, limitations, and prerequisites (tier). It addresses scope (EU/OFAC sanctions), data source (GLEIF), and coverage variability, making it complete enough for an agent to decide on invocation and set expectations.

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%, with both parameters already described in the schema (identifier as LEI or name, country as optional ISO code). The tool description repeats this and adds no new semantic detail beyond the schema. The example LEI in the schema is sufficient; the description's mention adds little 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 clearly states the tool produces an 'EU Due-Diligence report' with a specific input format and return content (GLEIF data + sanctions screening). It distinguishes itself from sibling tools like get_dd_report by specifying EU/OFAC sanctions and GLEIF coverage, making its purpose unambiguous.

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 this tool: for EU due-diligence on international companies, especially those with LEI codes. It does not explicitly contrast with sibling tools or state exclusions, but the context (EU focus, sanctions, GLEIF) provides clear guidance. The note about Pro Compliance tier and SME limitations also sets usage expectations.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds valuable behavioral context: the two-step lookup (ARES then GLEIF), the return fields (LEI, name, country, confidence), and the GLEIF coverage caveat. This goes beyond the annotations without contradicting them.

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

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

The description is three sentences with no wasted words. It front-loads the purpose, then concisely explains process, output, and limitations. 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 simple single-parameter lookup with no output schema, the description covers all essential aspects: the input type, the step-by-step process, the return fields, the coverage limitation, and the access tier requirement. It is complete for the tool's complexity.

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 provides full coverage of the single parameter 'ico' with description 'Czech IČO — 7 or 8 digits.' The description repeats 'Czech IČO' but adds no extra format or syntax details beyond the schema. Baseline 3 is appropriate given high schema 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 starts with 'Find the EU/international parent company for a Czech IČO,' which clearly states the verb and resource. It distinguishes itself from sibling tools by detailing the ARES→GLEIF lookup process and the specific output fields.

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: use for finding EU parent companies via ARES and GLEIF. It notes the Pro Compliance tier requirement and the GLEIF coverage limitation for SMEs, which implicitly tells users when not to use the tool. No explicit alternative is named, but the guidance is sufficient.

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 readOnlyHint annotation, the description discloses important behavioral traits: it returns 'structuredContent ownership tree plus markdown summary,' and that 'physical persons expose name and birth year only, never full birth date or address.' These additions give the agent a clear picture of output format and privacy constraints, going well beyond what annotations provide.

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 concise and front-loaded: the first sentence states the primary purpose, the second notes the free/anonymous nature, and the third covers return format and privacy. Each sentence adds distinct value without unnecessary fluff, making it easy to scan quickly.

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

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

Although there is no output schema, the description sufficiently explains the return format ('structuredContent ownership tree plus markdown summary') and important privacy redactions (birth year only). It also clarifies the scope ('direct and upstream') and the data source semantics, making it complete for an agent to understand what the tool does and what to expect.

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 provides full coverage of both parameters ('ico' and 'max_depth') with clear descriptions. The tool description does not add additional parameter-level semantics beyond what is in the schema; it only mentions 'member_ico edges' in the context of the tool's function, which is not a direct explanation of the parameters. Thus, the baseline of 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 states the tool's function with a specific verb ('Look up') and resource ('direct and upstream Czech VR owners'), including details on the type of ownership roles ('spolecnik/akcionar') and relationship edges ('member_ico edges'). This distinguishes it from sibling tools like get_statutory_chain or person_companies, which focus on different corporate aspects.

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 provides clear context on when to use the tool: for looking up Czech VR owners with real active shareholding roles and company-to-company member_ico edges. It also notes it is a 'Free anonymous tool,' implying no authentication is required. However, it does not explicitly name alternative tools or state when not to use this one, 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?

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds what data is returned (score, risk level, flags) and a performance trait ('Faster'), which is consistent with annotations and provides useful context beyond the safety profile.

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: first sentence lists returned fields and frames the tool as lightweight; second gives the usage scenario. Every word earns its place, with no redundancy or 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 simple 1-param read-only tool with no output schema, the description covers purpose, output content, and usage context adequately. It could mention error behavior (e.g., invalid ICO) but is largely complete for an agent to select and invoke 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% with the parameter 'ico' already described as 'Czech IČO — 7 or 8 digits.' The description adds no parameter-level detail, 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?

Description states a specific verb ('returns') and resource (numeric score 0-100, risk level, red flags), and explicitly distinguishes itself as 'Lightweight version of get_dd_report' while naming a sibling tool. This makes the purpose 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?

Explicitly identifies get_dd_report as the alternative and provides a clear usage condition: 'Faster when you only need a yes/no/maybe screen.' This gives strong when-to-use guidance, though it lacks an explicit 'when not to use' clause.

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

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

Annotations declare readOnlyHint and openWorldHint, but the description adds meaningful context: chronological sorting, specific event types, riskScore range (0-100), and tier requirement. It does not contradict annotations and provides more behavioral detail than the annotations alone.

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 sentences, front-loaded with the core purpose, and includes only essential details: event types, output shape, tier, and an alternative. No wasted words.

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 the single parameter and no output schema, the description sufficiently conveys the return structure (events[] with riskScore) and the tool's scope. It is complete enough for an agent to select and invoke correctly, though it could mention potential omissions or sources.

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 sole parameter 'ico' is fully described in the schema as 'Czech IČO — 7 or 8 digits', covering 100% of schema descriptions. The description does not need to add further parameter semantics, so 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 clearly states the tool builds a chronologically sorted lifecycle timeline for a Czech company and lists the event types included. It differentiates from the richer sibling tool by specifying 'basic events' and pointing to get_risk_timeline_rich for an enriched version.

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 'Pro Compliance tier or higher' as a prerequisite and directs users to get_risk_timeline_rich when an enriched timeline is needed. This gives clear when-to-use and when-not-to-use guidance, fulfilling the dimension well.

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 only indicate readOnlyHint and openWorldHint. The description adds valuable behavioral context: it is heuristic, noisy by design for common surnames, auto-skips persons with >50 matching companies, and produces a SURNAME_TOO_COMMON note. It does not describe output structure or failure modes, but these are secondary given the strong caveats 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?

The description is moderately sized but every sentence earns its place: purpose, best-use case, exclusion, alternative, and noise warning are all packed in without redundancy. It is front-loaded with the primary function. Slightly long but justified by the caveats.

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?

Even without an output schema, the description clarifies the tool's scope, limitations, and alternatives, which is essential for correct invocation. It does not describe the return format, but the walk-through nature and the note behavior give enough context for an agent to expect a chain-like result. Missing explicit output details prevent a 5.

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 already provides 100% coverage with descriptions for both 'ico' and 'max_depth'. The description adds context about surname-based heuristics and rare surnames, but does not significantly enhance parameter understanding beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool performs a 'surname-based heuristic walk through statutory bodies of related Czech companies'. It specifies the exact resource and action, and distinguishes itself from a true UBO source and sibling tools by noting it is best for shell-company unwinding with rare surnames.

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 explicit guidance on when to use ('Best for shell-company unwinding in small s.r.o. with RARE surnames'), when not to use ('NOT a true UBO source'), and names the alternative ('use the ESM'). It also warns about common surnames and the auto-skip behavior, giving clear decision criteria.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds significant behavioral detail: output exposes only birth_year (never full birth date), and same-name person_ids are kept separate with a distinguisher. This goes beyond the annotations and informs the agent about privacy-preserving behavior and disambiguation, which is genuinely useful.

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 three sentences, each earning its place: core purpose, free anonymous nature, and input/output behavioral specifics. It is front-loaded with the main verb and resource, and contains no redundant filler or repeated structured data.

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 covers return behavior well by stating the output's constraints (birth_year only, never full birth date, same-name person_ids separated). It implies the output is companies, given the lookup purpose. Slight gap: it doesn't explicitly enumerate other output fields, but it is adequate for a simple lookup 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?

Schema description coverage is 100%, with both 'name' and 'birth_year' already described. The description adds minimal extra parameter semantics—it repeats that input accepts a public name and optional birth year, but does not clarify anything beyond the schema. Therefore the baseline of 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 states a specific verb ('Look up') and resource ('Czech VR companies'), and further specifies the join path ('exact registry person_id -> roles -> companies joins'). This clearly differentiates it from sibling detection/risk tools, which focus on analysis rather than basic lookup.

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 provides clear usage context: it's a free anonymous lookup for exact matches in the Czech VR registry, requiring a public name and optionally a birth year. It implies its use when you need company associations by person, and the sibling set (detection tools) is obviously different. However, it does not explicitly state exclusions or alternatives, 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?

The description discloses key behavioral traits beyond annotations: it's a stub that persists nothing, returns specific statuses and flags, and instructs the agent not to open the onboarding link or submit data on the user's behalf. This is exactly the kind of context annotations cannot capture.

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 sentences, front-loaded with purpose, and every clause adds value: stub status, return payload, and user responsibility. No fluff or repetition.

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 the simple schema and lack of output schema, the description fully explains return values (status enum, flags, next_step.url, pricing) and clarifies the manual onboarding step. This is complete for an MCP tool with one parameter.

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% with the 'ico' parameter already described as 'Czech IČO — 7 or 8 digits.' The description adds no further parameter details; the baseline of 3 applies because the schema carries the burden and the description doesn't undercut or enrich 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 description clearly states the tool's purpose: starting onboarding for monitoring a Czech company by IČO. It uses a specific verb ('Start onboarding') and resource ('monitoring of one Czech company'), and distinguishes itself from sibling detection/report tools by focusing on the watch/onboarding flow.

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 context implies when to use (user wants to monitor a company), and sibling tools are clearly different (detection reports, ownership lookup). However, it lacks explicit exclusions or alternatives, so it doesn't fully meet the 'explicit alternatives' bar.

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