Skan Firmy

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

With no annotations provided, the description carries the behavioral disclosure burden. It covers required authentication (API key), scope (NIPs you monitor), temporal behavior (changes since a date), and output subject (VAT status/bank accounts). It does not state response shape or explicitly guarantee non-mutation, but 'Return changes' and the polling framing imply a read-only operation.

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 compact sentences: one states what the tool returns and the frame of monitoring; the second establishes the polling use case and auth requirement. There is no filler, and the core operational details come 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?

The definition covers the essential facts an agent needs to choose or invoke this tool: what is returned, for whom, since when, for what purpose (polling), and the API-key prerequisite. It lacks details such as pagination or response structure, but the tool has no output schema and both parameters are fully documented, so the description is sufficient for correct use.

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

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

Schema coverage is 100%, so the schema already documents both `since` and `api_key` well. The description adds marginal semantic value by reinforcing the API-key requirement and the date-anchored behavior, but it does not provide detail beyond what the parameter descriptions already give.

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: 'Return changes' detected since a date for monitorowanych NIPs. It enumerates the change kinds (VAT status or bank accounts) and identifies itself as a polling channel, which clearly differentiates it from one-shot query 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?

Describes itself as 'polling channel for agents', which makes the intended usage pattern clear: periodically fetch changes rather than receiving push events. It does not explicitly name alternative tools such as set_webhook, so it misses the strongest when/when-not wording, but the context is unambiguous.

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 alone takes the burden of behavior. It says only 'Generate... from a NIP or PESEL' and says nothing about idempotency (whether the same identifier always produces the same account), whether an external call is made, whether the result is already paid as-the-case for tax micro-accounts, or required credentials. The core behavioral nuance of 'generation' versus 'creation' is left unexplored, which is a meaningful gap for a mutation-named tool.

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 one front-loaded sentence that opens with the operative verb and target, follows with the domain (PIT/CIT/VAT), and closes with the input type. There is zero filler, no redundancy, and it is appropriately short for a one-parameter 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?

The tool has a single parameter, but also no annotations and no output schema, so the description carries full context burden. It covers the input form of and the payment type of the purpose adequately, but never describes the return value (e.g., the produced micro-account number) or failure handling for invalid identifiers. For a simple tool this is adequate yet lacks edge-case and return-format 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 description coverage is 100% — the schema already documents 'identyfikator' as 'NIP (10 digits) or PESEL (11 digits).' The description's 'from a NIP or PESEL' largely echoes the schema's content without adding new syntax, format, or edge-case details. Baseline 3 is appropriate when the schema does the heavy lifting.

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 concrete, specific operation: 'Generate the individual tax micro-account... from a NIP or PESEL.' It names the verb, the resource, and the target purpose ('for PIT/CIT/VAT payments'), differentiating it clearly from sibling tools (e.g., sprawdz_nip, sprawdz_rachunek, which check/examine, not generate). An agent can distinguish it from siblings 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 implies when to use the tool — when a tax micro-account for PIT/CIT/VAT payments is needed from a NIP or PESEL — but it does not explicitly mention alternatives or exclusion conditions. Sibling names (sprawdz_nip, sprawdz_rachunek, oblicz_odsetki) make the difference somewhat inferable, yet reuse guidance is not stated.

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

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

The description indicates an authentication requirement and clearly conveys that the operation returns data, which implies a read-only action. However, with no annotations at all, it leaves other behavioral context undisclosed, such as whether there are pagination limits, whether the data may be stale, or whether existing observations are only listed without side effects.

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 short sentences, front-loads the main purpose, and contains no filler. Every sentence adds relevant information, whether it is the return contents or the authentication requirement.

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 list operation, the description names the returned data and the authentication requirement. It does not document response structure, ordering, or optional behavior with empty monitoring lists, but overall it is reasonably complete for its scope.

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 covers the single `api_key` parameter at 100% coverage, including the header-fallback behavior. The description merely repeats the requirement for an API key and does not add additional semantic 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?

The description clearly names a specific verb and resource: it returns the list of NIPs being monitored and what data accompanies them, the current VAT status and last-checked date. This differentiates it from monitoring actions like observe_nip/unobserve_nip, though it doesn't explicitly contrast with potentially similar sibling `sprawdz_lista_nip`.

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 'the NIPs you monitor' implies when the tool is useful, but there is no explicit guidance about when to prefer it over sibling tools, nor any when-not-to-use cases. It could more strongly differentiate itself from `sprawdz_lista_nip` or `changes_since`.

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 full behavioral transparency burden. It does add one meaningful behavioral fact beyond the schema: the interest is calculated by NBP reference-rate periods. However, it does not describe return format, rounding, or edge-case behavior, which a pure calculation tool could reasonably disclose.

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

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

A single front-loaded sentence captures the core purpose and the distinctive breakdown behavior. There is no filler, and every word contributes useful meaning.

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?

Parameters are fully documented and the computational behavior is sketched clearly, but there is no output schema and no statement about what the result contains. For a straightforward calculator this is mostly sufficient, but additional output details would make the definition more 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 description coverage is 100%, and the schema already explains typ variants, overdue amount in PLN, and date formats. The description adds no per-parameter information, so baseline 3 is appropriate; the schema does the work, not 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 states a precise verb and resource: calculating statutory or commercial B2B late-payment interest, with a distinctive detail about splitting the calculation by NBP reference-rate periods. No sibling tool has the same purpose, so there is little risk of confusion.

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 makes the intended context clear: statutory vs commercial B2B interest, broken down by reference-rate periods. It does not explicitly name alternatives or exclusions, but none of the visible siblings is an interest-calculating alternative, so the context is strong enough.

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 full burden. It successfully discloses the side effect (registering a NIP for monitoring), the authentication mechanism (Authorization header or api_key argument), and the free-plan limit. It omits some details like duplicate handling or exact response output, but it is substantially transparent for a simple registration operation.

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, front-loaded with the core action, and every sentence adds relevant detail: what the tool does, how you get notified, auth requirements, and the plan limit. No filler or redundant repetition of schema or title.

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 tool with no output schema, the description covers the essential context: purpose, result, auth, and constraints. It could be improved by mentioning what happens on duplicate registration or what the API returns, but these are secondary and the description is sufficiently complete for an agent to decide to call it correctly.

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

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

The schema already documents both parameters with 100% coverage. The description adds useful auth context for api_key and clarifies notification conditions for the nip parameter, but it doesn't add significant new semantics 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?

The description clearly states the action ('Add a NIP to monitoring') and the resource affected, and explains the resulting behavior: notifications when VAT status or bank account data changes. This makes it easily distinguishable from sibling tools like unobserve_nip, list_observations, and changes_since.

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 context for when this tool is relevant: you use it to start monitoring a NIP and are then notified via changes_since or email. It also gives a prerequisite (API key) and a usage constraint (free plan limit of 10 NIPs), though it does not explicitly say when not to use it or contrast with 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?

No annotations are provided, so the description fully carries the behavioral burden. It discloses the exact signing algorithm (HMAC-SHA256), the signature header name, the one-time secret return, the disable behavior, API key requirement, and the https-only restriction. This gives the agent a complete safety and side-effect picture for a mutating configuration tool.

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 front-loaded with the core purpose. Every sentence earns its place: purpose, behavior, return nuance, disable path, authentication, and URL restriction. No redundant filler or repetition of the tool name/title.

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

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

For a two-parameter, no-output-schema tool, the description covers all significant operational aspects: how the webhook is triggered, the signature scheme, the secret response, disabling, API key usage, and network constraints. No critical behavioral detail is left to guesswork, making the tool safely callable by an agent.

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%, but the description adds meaningful context beyond the schema: 'Returns the secret ONCE', 'Pass an empty url to disable', 'Public https addresses only (port 443)', and the requirement for a skanfirmy API key. These details clarify expected values and response behavior, elevating the baseline schema-documented semantics.

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 action ('Set (or clear) a push webhook URL for your monitoring') and specifies the resource. It differentiates webhooks from polling and is not a tautology. The verb-target pair is unambiguous and distinct from sibling tools such as observe_nip or changes_since.

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 explicitly frames when to use this tool: 'instead of or in addition to polling,' which gives clear context for push vs pull workflows. It does not name specific sibling tools or state when not to use it, but the polling contrast effectively conveys the primary usage. A stronger version could name alternatives like changes_since as the polling counterpart, but the guidance is already 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, the description carries the full disclosure burden, and it does disclose the rate limits, the 30-entry cap, and that it explicitly does not fetch full KRS data. It falls just short of scoring 5 the exact consequence of exceeding the 500/day quota and no description of result structure beyond listing the returned fields, but the behavioral coverage is substantially above what would minimally be expected.

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 compact sentences with zero filler: core function in sentence one, use case in sentence two, limits in sentence three, and an exclusion with routing in sentence four. Each observation earns its place. The most decision-relevant facts are 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 single-parameter bulk look-up with no annotations and no output schema, the description is remarkably complete: it states what data each entity result contains, the rate limits, and the limit case of the scope (no full KRS). It is not a 5 because it doesn't say how rate-limit-exceeded or partially-valid requests are surfaced in the response.

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% — the nipy parameter is already fully described in the schema including 1-30 count, digit checksum, and invalidInput behavior. The description only repeats 'up to 30 NIPs' and adds no new parameter-level meaning, matching the baseline for high coverage.

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

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

The description names a specific verb ('Bulk-check'), a specific resource ('Ministry of Finance VAT White List'), and enumerates exactly what is returned (VAT status, bank accounts, REGON, KRS, address). It also actively distinguishes itself from the sibling sprawdz_nip, so an agent cannot confuse the bulk list tool with the single-entity 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?

The description gives an explicit use case ('For verifying a portfolio of counterparties'), states operational constraints (max 30 NIPs per call, ~500 bulk queries/day per IP), and names the alternative tool for the complementary case ('use sprawdz_nip for individual entities'). An agent receives 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?

There are no annotations, so the description carries the behavioral disclosure burden. 'Check' clearly suggests a read-only query, but the description does not explicitly state side effects, read-only behavior, data freshness, authentication, rate limits, or response expectations.

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

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

One concise, front-loaded sentence. It conveys the action, target, and scope with no filler or redundant restating of the tool name.

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 definition is mostly complete: the input is documented well, and the goal of the operation is clear. The lack of output schema and annotations leaves return-value details or caveats implicit, but the simplicity of the tool compensates.

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 already documents `nip` as the 10-digit Polish tax ID, and schema description coverage is 100%. The description adds no additional parameter detail, so the 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 names the action (check), the resource ('VAT status (Biała Lista) and KRS data'), and the input condition ('Polish company by NIP'). This is enough for an agent to separate it from VIES, REGON, and other sibling lookup 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?

The context is implicit: use it when you need to verify a Polish company's VAT status or KRS data by NIP. However, it does not explicitly mention when not to use it, nor does it compare itself with similar siblings such as `sprawdz_lista_nip`.

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 of behavioral disclosure. It states the core verification behavior against the White List but does not clarify the exact return format (e.g., only true/false vs details like account owner or account status), error handling for invalid NIP/NRB formats, or whether the tool only checks membership or also active status. This is a moderate gap given the absence of 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?

The description consists of exactly two sentences with no filler. It front-loads the core action and follows with the business context, making it scannable and directly informative 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 simple 2-parameter tool with no annotations and no output schema, the description covers what the tool does but omits what the agent can expect to receive back. A tool that returns not only 'present/absent' but possibly ownership or active-status details would commonly badly start inferring from the schema. Given the missing frame around return value and error semantics, the definition is adequate but not 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?

The input schema fully describes both parameters with lengths and format (10-digit NIP, 26-digit NRB without PL prefix), so schema coverage is 100%. The description's added value is the relational context: it makes clear the numerRachunku is checked against the VAT White List of the provided nip, a semantic connection not explicitly stated in the property descriptions alone.

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: 'Check whether a bank account number (NRB) appears in the VAT White List for a given NIP.' This clearly distinguishes it from sibling tools that check NIPs (sprawdz_nip), REGONs (sprawdz_regon), or lists of NIPs, and it identifies the specific White List domain.

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 the regulatory context of 'due diligence for payments above PLN 15,000,' which signals when an agent should invoke this tool. It does not explicitly name alternatives or exclusions, but the account-specific scope is sufficiently distinct from sibling tools that the intended use is evident.

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 behavioral disclosure burden. It correctly conveys a read-only lookup action and discloses the depth of coverage and the fields returned. It does not mention error cases or MOC data freshness, but the main behavioral characteristics are clearly stated.

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 dense, purposeful sentences: one states the action and output fields, the other emphasizes coverage. There is zero filler, and the most important identifying 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?

Given the simple single-parameter lookup with no output schema, the description covers the source, the input, expected output fields, and the important scope note about sole proprietors not in KRS. It is adequate for an agent to select and call the tool, though it omits impossible edge-case behaviors such as how invalid NIPs are reported.

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 already documents nip as a 10-digit Polish tax ID, and schema description coverage is 100%. The description adds 'by NIP' but does not expand on parameter formatting, validation, or normalization, so the description provides no meaningful value above 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 states the operation and resource: 'Look up entity data in the REGON register' by NIP, and lists the returned fields. It also conveys a broaded scope than KRS-based lookups, though it does not explicitly differentiate from the sibling tools that might also involve NIP without naming one.

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

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

The phrase 'by NIP' and the note 'Covers ALL entities, including sole proprietors that are not in the KRS' provide clear context for when this lookup is appropriate. It doesn't explicitly recommend this tool over alternatives, but it gives enough functional context for an agent to select it when NIP-based REGON registration data is needed.

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. It does disclose an external dependency ('European Commission VIES system'), which is useful. However, it does not mention potential VIES availability/latency issues, errors for invalid country codes, or whether the operation is read-only. This is adequate but not highly 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?

One sentence, no filler, and the core action is front-loaded. Every word either identifies the operation ('Validate'), the resource ('EU VAT number'), or the system context ('VIES system'). This is ideal conciseness.

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 (2 parameters) and the schema covers parameters well, but there is no output schema and the description does not state what the validation result looks like or how to interpret failures. For an agent, the missing return behavior is a distinct gap, so the definition is only moderately 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?

The input schema already fully documents both parameters with clear descriptions and an enum for countryCode. The tool description adds no parameter-specific meaning beyond what the schema provides, so the 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?

Description states a clear verb ('Validate') and a specific resource ('EU VAT number in the VIES system'), immediately distinguishing this from sibling tools that handle NIP, REGON, or account numbers. 'VIES system (European Commission)' adds authoritative context and leaves no ambiguity about what the operation is.

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 frames when to use the tool: for validating EU VAT numbers via VIES. It does not explicitly list alternative tools, but the sibling names (sprawdz_nip, sprawdz_regon, sprawdz_rachunek) make the VIES target distinct and the intended use reasonably clear. Missing explicit exclusions keeps it from a 5.

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

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

With no annotations provided, the description carries the full burden, and it discloses useful runtime behavior: results are matching entries with links to official docs, an empty query degrades to catalog-wide listing, and the query can be narrowed by scope or topic. It does not address result ordering, pagination, or how relevance is computed, but for a non-destructive catalog search the key behaviors are covered.

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 earn their place: the main action and scope, the return value, and the empty-query/narrowing behavior. The opening verb is front-loaded, and the parenthetical category examples add disambiguation without padding.

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 medium-low complexity tool with zero required parameters, a 100% documented schema, and no output schema, the description tells an agent what the input means, how to invoke it with no args, and what the result shape is (matching entries with links). The only openness is a lack of detail on pagination or result count limits, which is a common pitfall in search tools but not blocking for correct usage.

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, and the description adds value above that by explaining how the parameters relate: an empty zapytanie returns the whole catalog and that zasieg/temat act as narrowing filters. It also contextualizes the values of tematy and zapytanie with examples that reinforce the idiomatic use of the tool.

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+resource pair ('Search otwarteAPI.pl, a catalog of public Polish and EU APIs') and immediately differentiates the tool from siblings like szukaj_pkd, sprawdz_nip, and sprawdz_vies by clarifying it finds APIs rather than examining specific entities. The concrete list of catalog categories (VAT, KRS, GUS, NBP, ECB, Eurostat) pins down its scope unambiguously.

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 conveys the usage context — discovering public APIs by natural-language query, scope, or topic — and explains the empty-query behavior so an agent knows when to call it with zero arguments. It does not explicitly state when not to use it or name an alternative, but the context is specific enough that an agent can distinguish it from the entity-lookup siblings.

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

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

No annotations are supplied, so the description carries the full burden. It clearly implies a read-only search operation, but it does not disclose what the tool returns, whether results are limited, or any access requirements. For a simple search tool this is acceptable but not richly 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?

The description is a single, front-loaded sentence with no filler. It identifies the tool's action, resource, and searchable fields in a compact and scannable way.

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 search tool, the description is essentially complete: it tells the agent which domain is searched (PKD 2025), what the input can be, and what the tool is for. The lack of an output schema is not a barrier for this simple lookup operation, though output details would strengthen completeness.

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 parameter schema fully documents 'zapytanie' with type and examples, and the description largely restates that same information. With 100% schema coverage, the appropriate baseline is 3; the description adds no meaningful extra meaning 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 states a specific verb ('Search'), a specific resource ('PKD 2025 business activity codes'), and the exact search criteria ('activity name or code number'). This unambiguously tells an agent what the tool operates on and clearly separates it from sibling tools dealing with NIP, REGON, or other 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 intended use case is implied by the description: use this tool when you need to look up a PKD code by name or numeric code. However, there is no explicit guidance about when to choose it over the similar-looking sibling szukaj_katalog_api, nor any exclusions or alternative routing.

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 present, so the description carries the full burden for behavioral disclosure. It does not state whether removal is idempotent, what happens to existing observation history, whether the operation can fail if the NIP is not monitored, or what the return value will be. The API key requirement is helpful but minimal for a mutating operation.

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 sentence with no filler, front-loads the core action, and directly conveys the operation. It is concise 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?

The tool is destructive and lacks both annotations and an output schema. The description omits error behavior, success indicators, prerequisites beyond the API key, and how the removal relates to list_observations. This is too sparse for a mutation 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 schema has 100% coverage for both parameters, so the description is not required to document them further. It does reinforce that 'nip' is the monitoring target, but it adds essentially no new semantics 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 uses a specific action and resource: 'Remove a NIP from monitoring.' It clearly distinguishes this tool from related siblings such as observe_nip and list_observations by stating the inverse monitoring operation.

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 the use case: whenever a NIP should be removed from monitoring, this is the tool. However, it does not explicitly mention alternatives or state when not to use it, leaving some inference to the agent.

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