Polish KYB

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

Annotations already declare readOnly, idempotent, non-destructive and non-open-world, so the safety profile is covered. The description adds the data scope (what the profile contains) but says nothing about lookup failure, ambiguous name matches, rate limits, or the fact that at least one identifier is effectively needed despite zero required parameters.

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

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

Two sentences, both earning their place: the first front-loads the returned fields, the second handles identification and routes to the fallback tool. 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 usefully enumerates the profile contents, which is exactly what the agent needs to judge whether this tool returns what it wants. The gap is that zero required parameters are declared while the prose implies one identifier is mandatory, and no failure behavior is described.

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's note on identifying a company by name, KRS or NIP largely restates the schema, which already labels 'name' as the fallback when KRS/NIP is unknown; no extra format, priority, or conflict-handling detail is added.

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 plus resource ('get the registry profile of one Polish company') and enumerates the fields returned (legal form, PKD, share capital, representation rules, VAT status, financials). It also scopes itself away from the EU-funds/grants/tenders siblings by framing the output as a registry profile rather than a program-specific dataset.

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 names an alternative and the condition for it: 'For earlier years or full statements use get_financials.' It also gives the three acceptable lookup keys, which tells the agent how the tool is invoked. It stops short of saying when NOT to use this versus the get_company_eu_* siblings, so a 5 is not warranted.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the retrieval source (a court register document repository), but says nothing about document availability, language, truncation, or paging. Some added context, not rich.

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

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

Three sentences, front-loaded with the core action, then usage triggers, then identification. Efficient overall, though the final identification sentence largely duplicates what the schema already states.

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

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

With no output schema, the description correctly notes the return is document text, and the document-repository source plus topical use cases give the agent enough to call it. Gaps remain around ambiguous name resolution and behavior when no articles exist, which matter for a tool with all-optional parameters.

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

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

Schema description coverage is 100%, so KRS, NIP, name and doc_id are fully documented in the schema itself. The third sentence restates the identifier options (name/KRS/NIP) without adding meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get the text of a Polish company's articles of association or statute') plus the source ('court register document repository'), which cleanly separates it from the other get_company_* siblings. An agent can identify the tool without opening the schema.

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

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

The second sentence gives explicit topical triggers (share transfers, pre-emption rights, voting rights, management board powers, company duration), which is clear when-to-use guidance. It stops short of naming when NOT to use it or pointing to a sibling alternative (e.g. get_company for general company data).

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 this a safe, idempotent read (readOnlyHint, idempotentHint, destructiveHint=false), so the bar is lower. The description adds genuine non-obvious context beyond them: PESEL is never returned (only birth_year), all names are returned, and JDG entities are out of scope. It still says nothing about authorization or coverage/latency, so it stops short of 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?

Three short, front-loaded sentences with no filler; the key scope statement leads. The parenthetical '(same as zarząd / wspólnicy)' is slightly cryptic and adds ambiguity rather than clarity, keeping it just below 5.

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

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

There is no output schema, so the description must carry return-value information, and it does disclose the important output traits (names included, birth_year instead of PESEL, JDG excluded). That is sufficient to call the tool correctly, though the fallback behavior among the three optional parameters is left implicit.

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

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

Schema description coverage is 100%, so krs, nip, and name are already documented in the schema with formats and fallback logic. The description adds no additional meaning about these parameters or precedence between them, which is the baseline 3 when the schema carries the load.

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: CRBR beneficial owners for a KRS company, scoped to the Polish register context. It partially differentiates from the sibling get_company_people by noting the returned names are 'same as zarząd / wspólnicy', but it does not explicitly contrast the two tools, so an agent must infer the distinction.

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

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

Provides one useful exclusion ('JDG are not in CRBR'), which tells the agent when the tool is not applicable. However, it never names an alternative tool (e.g., get_company_people) or states the positive condition for choosing CRBR data over the general people lookup, leaving the when-to-use decision implied.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description's help. The description adds useful content-level context by enumerating the notice types surfaced (creditor calls, liquidation, mergers/transformations), but says nothing about coverage, freshness, or what an empty result means.

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

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

Two sentences, both load-bearing: the first defines the resource and its contents, the second covers identification. The most important information (what the tool returns) is front-loaded with no filler.

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

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

For a zero-required-parameter, read-only lookup with all three params documented and a full safety annotation set, the description supplies enough to call it correctly. With no output schema, the agent still lacks any sense of result shape or whether results can be multiple/paginated, which keeps this short of 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?

Schema description coverage is 100% and all three identifiers (KRS, NIP, name) are documented per-parameter, including the '10 digits' formats and when to fall back to name. The description's sentence about identifying the company adds no syntax or precedence detail beyond what the schema already states, 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?

States a specific verb ('Get'), a precise resource ('notices about a Polish company published in the Court and Commercial Gazette') and enumerates the notice categories returned (calls to creditors, liquidation, mergers and transformations). This is clearly distinguishable from siblings like get_company_debt_registry or get_company_beneficiaries, which cover different data domains.

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 no when-to-use or when-not-to-use guidance and names no alternative or complementary sibling tool. The only directive ('Identify the company by name, KRS number or NIP') is identifier selection, not usage guidance, and it largely restates the input schema.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds that the data comes from the Polish KRZ register, but says nothing about result completeness (e.g., empty result meaning 'no proceedings'), rate limits, or whether identifiers can be combined. A 3 is appropriate given annotations carry most of the burden.

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

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

Two tightly written sentences: the first front-loads what is retrieved and from where, the second covers identification. Nothing is wasted and the key information comes first.

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 lookup tool with no output schema, the description covers purpose, source, and identification adequately. It could be slightly stronger by clarifying that zero results mean no recorded proceedings, but nothing essential for correct invocation is missing.

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 each parameter is already documented, including the fallback nature of 'name'. The description's mention of the three identifiers is redundant with the schema and adds no format, precedence, or combination guidance beyond it. 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 gives a precise verb (get), resource (insolvency and restructuring proceedings), and names the specific source (National Debtors Register / KRZ). It is clearly distinguishable from siblings like get_company_sanctions, get_company_court_gazette, and get_company_financial_supervision, which cover different registers.

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 states how to identify the company (name, KRS, or NIP), which implies usage but never says when to reach for this tool versus the other get_company_* siblings or what to do when no identifier is available. There are no explicit when/when-not conditions or named alternatives.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the NIP keying and the null-return semantics when a company has no KNF entry, which an agent needs to interpret an empty result.

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, zero filler. It front-loads the register's identity and scope, then closes with the keying and null behavior an agent needs for result interpretation.

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

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

With no output schema, the description usefully names the returned fields (kind, KNF number, status, registration/decision/strike-off dates, services) and the null case. All three parameters are optional and schema-documented, so the definition is nearly complete; only explicit alternative-routing guidance is missing.

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

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

Schema description coverage is 100%, so the schema already documents krs, nip, and name fully. The description's 'Keyed by NIP' hints at a preferred lookup key but adds no format, precedence, or fallback detail beyond what the schema provides.

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

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

States a specific verb+resource — the KNF register of licences and entries for a financial company — and enumerates the entity types it covers (banks, payment/e-money institutions, insurers, agents). The topic is distinct from every sibling (debt registry, sanctions, court gazette), so an agent can route to it without opening the schema.

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

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

The description says the tool is 'Keyed by NIP' and returns null when no KNF entry exists, which implies usage, but it never states when to prefer this over siblings or what prerequisites apply. No exclusions or alternative-routing guidance is given.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful return context beyond annotations by naming the kinds of people records and relationship labels returned, but it does not mention pagination, result limits, or authentication constraints.

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 tightly written sentences with zero waste, and it front-loads the core purpose before enumerating categories and identifiers. Every clause earns its place by either clarifying scope or identifying the return values.

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

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

For a read-only, closed-world lookup tool with 100% schema coverage and explicit annotations, the description is nearly complete: it explains the resource, its subcategories, the return labels, and identifier options. The main minor gap is the lack of pagination or result-size expectations, but with no output schema and simple parameters, this does not leave a critical ambiguity.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema. The description restates that the company can be identified by name, KRS, or NIP and names the relationship types, but it adds no syntax, format, or filtering detail beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description states a specific verb ('Get') and resource ('people associated with a company') and enumerates the relevant categories: management board, supervisory board, shareholders, proxies. It is clear about what is returned, but it does not differentiate this tool from close siblings such as get_company_beneficiaries, which likely surfaces overlapping ownership information.

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 no when-to-use or when-not-to-use guidance relative to alternatives. It only explains identifier choices (name, KRS, NIP), which is parameter usage rather than tool-selection guidance, so an agent receives no explicit routing advice for choosing this tool over get_company, get_company_beneficiaries, or others.

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 establish readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds genuinely non-derivable context: the result is null when unlisted and the payload duplicates get_company's sanctions field, both of which affect how an agent interprets an empty response.

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

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

Four short sentences, front-loaded with the resource identity, then return shape, then matching, then the de-duplication note. No filler and every sentence carries operational information.

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

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

With no output schema, the description correctly carries the burden of describing the return ('measures and legal grounds', or null). It is nearly complete for a three-key lookup, missing only multi-match behavior and the REGON reference that the schema does not support.

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 three keys are documented there, giving a baseline of 3. The description adds the fact that matching works by KRS, NIP or REGON, but REGON is not a parameter in the schema, and with 0 required params it never says which key takes precedence on a mismatch.

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 ('Official MSWiA sanctions listing for one company') and immediately distinguishes it from the sibling set by noting the same payload is also embedded in get_company. An agent can tell this apart from get_company, get_company_debt_registry, etc., without opening any schema.

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

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

The line 'The same payload is included on get_company as sanctions' gives the agent a real basis for choosing between the two tools (skip this call if you already fetch get_company). It stops short of an explicit 'use this when / not when' rule, and gives no guidance on which of the three lookup keys to prefer.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false/openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: the coverage window ('period ending 2025+'), the primary key (KRS), and the explicit null-when-undisclosed behavior for a read tool whose empty result could otherwise be ambiguous.

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

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

A single dense sentence plus a short trailing clause; the resource is front-loaded and no sentence is filler. It is information-packed but readable and appropriately sized.

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

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

With no output schema, the description carries the return-value burden and does so adequately by naming the fields (creditor, amount, secured debt, asset, KW numbers) and the null case. Minor gap: no guidance on choosing among the three identifier parameters.

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

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

Schema description coverage is 100%, so all three identifier parameters are already documented with format details (10 digits). The description only adds 'Keyed by KRS' and does not resolve precedence among krs/nip/name, so it stays at the baseline.

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 (secured liabilities from financial-statement notes) and enumerates exactly what is returned (mortgages, pledges, transfers, assignments) with the fields attached. This clearly separates it from siblings like get_financials and get_company.

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

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

Usage is implied by the content scope and the note that results are 'keyed by KRS' and 'null when nothing is disclosed', but the description never says when to prefer this tool over get_financials or any alternative, nor are prerequisites or exclusions named.

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 establish readOnly/idempotent/non-destructive/closed-world, so the bar is lower, and the description still adds real behavioral context: quotes are delayed ~15 minutes, values are in PLN, the TTM P/E falls back to the last annual filing, and the payload is a snapshot plus a few daily bars rather than full OHLCV history. It stops short of stating auth requirements, rate limits, or behavior when the company has no listing.

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

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

It is a dense but well-structured pair of sentences that front-loads the resource and then the returned fields, which is justified given there is no output schema. The long field enumeration is functional rather than padding, though it could be tightened slightly.

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

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

With no output schema, the description carries the burden of describing return values and does so thoroughly, including units (PLN), latency (15-minute delay), and scope limits (snapshot, not full history). The remaining gap is failure/edge-case behavior — no listing found, multiple name matches, or which identifier wins — which an agent would want for a zero-required-parameter 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%, so the three parameters (krs, nip, name) are already documented, and all are optional. The description restates the same identification guidance ('Keyed by NIP'; 'Identify company by name, KRS, or NIP') without adding format or precedence detail beyond the schema, 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?

The description gives a specific verb+resource ('Get Warsaw Stock Exchange listing for a company') and then enumerates exactly what is returned (ticker, ISIN, market, close/change, market cap, EPS, P/E, dividends), which cleanly separates it from the sibling registry tools like get_company or get_company_people. An agent can tell this is the market-data tool without opening any schema.

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

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

It gives the lookup key guidance ('Keyed by NIP', 'Identify company by name, KRS, or NIP'), which is useful selection context. However, it never contrasts itself with the obvious sibling get_company (company registry data), nor states when-not to use it (e.g. for historical OHLCV, which it only hints at). Usage is therefore implied rather than directed.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds value beyond that by spelling out the exact metrics returned plus the inclusion of limits and reset date, which is the key behavioral context for a quota tool and is especially useful given there is no 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?

One front-loaded sentence naming the resource, then an em-dash list of metrics and a short clause on limits and reset date. No filler, and the highest-value information (usage + remaining quota) comes first.

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

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

With no output schema, the description carries the return-value burden and does so by listing the metric keys, limits, and reset date. What remains missing is scope (which account/workspace the usage applies to) and the relationship to get_plan, both minor for a no-arg read 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 tool takes zero parameters, so the baseline is 4. The description cannot add parameter meaning, and none is needed; the enumeration of metrics describes the response rather than inputs, which is a reasonable substitute.

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 ('Get') and resource ('current billing period usage and remaining quota') and enumerates the five metric buckets returned. It is clear what the tool does, but it never differentiates itself from the related sibling get_plan, so an agent must infer the boundary between 'usage/quota' and 'plan'.

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

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

The phrase 'current billing period' implies a reporting context, but there is no statement of when to call this versus get_plan, get_financials, or the key-listing tools, and no mention of prerequisites or account scope. Usage is left entirely to inference.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description goes well beyond them: the RODO gating that hides companies without a public email, the sparse-result `hint` behavior, and the client-size risk of fields=full. That is meaningful operational context the annotations cannot convey.

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

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

Dense but front-loaded: purpose, then scope exclusions, then field modes, then use cases, then the anti-pattern. Every sentence carries information, though the field-mode details partially duplicate the enum descriptions in the schema.

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

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

For a 35-param tool with no output schema, the description supplies the return-shape semantics for each fields mode, the RODO/JDG limit on result coverage, and the hint signal on sparse results — everything an agent needs to interpret and size its calls.

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% across 35 params, so the baseline is 3, but the description adds genuine meaning: the three fields modes and their exact contents, and combination recipes like registration_date + sort_dir=desc for newest registrations and revenue_growth_pct + revenue_min for fast-growing companies.

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 ('Search and filter Polish KRS companies') and immediately scopes what it does not cover (JDG/CEIDG browsing). An agent can distinguish it from get_company and export_companies without opening a schema.

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

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

Enumerates concrete use cases (rankings, sector filters, city/county/region browsing, name search, NIP/KRS lookup) and names the anti-pattern explicitly: 'Do not call export_companies just to get a handful of emails or phones.' It also flags the JDG exclusion, so the agent knows when to look elsewhere.

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