Skowron Compliance Gateway

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

The description adds a caution that it is 'Not legal advice', which is a useful disclosure. However, it does not explain the behavior beyond 'screen' or mention limitations, side effects, or what the screening entails. Annotations already cover read-only and idempotent nature, so the bar is lower, but the added context is minimal.

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, concise sentence that avoids unnecessary detail. It is well-structured and directly to the point, with no 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?

The description is incomplete regarding the tool's output and how to interpret the screening result. It does not mention the return format, possible outcomes, or any contextual details about the EU AI Act applicability criteria. This lack of context makes it difficult for a user to know 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 description provides no information about the input parameters (e.g., biometric, education, employment, etc.). It does not explain how these fields are used in the applicability screening. The schema has low coverage, and the tool description fails to compensate.

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 as an 'EU AI Act compliance / AI Act applicability screen', referencing the official regulation. It is specific and distinct from sibling tools like OFAC screening or VAT validation.

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 does not provide any guidance on when to use this tool over alternatives, nor does it mention conditions, prerequisites, or typical use cases. It simply states what the tool does without 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds 'Informational screening, not legal advice' – a useful caution that the results are non-authoritative and not legally binding. This adds value beyond annotations without contradicting them. However, it doesn't disclose return format, edge cases, or rate limits, so a 3 is appropriate.

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 sentence, front-loaded with the core purpose, and includes a necessary disclaimer ('not legal advice'). It's concise, though the triple phrasing ('Company compliance API / regulatory applicability / compliance preflight') is slightly redundant. No filler or fluff.

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

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

For a tool with 9 parameters and no schema descriptions, the description should explain what the tool does with those inputs. It only says 'regulatory applicability' and 'screening,' which is vague. There's no mention of output format (though output schema exists) or how parameters like 'uses_ai' or 'takes_card_payments' factor in. Annotations cover safety, so the gap is on usage scope and parameter behavior.

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

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

Schema description coverage is 0%, and the description provides no explanation of how parameters like 'uses_ai', 'takes_card_payments', or 'processes_personal_data' influence the screening. The parameter names are self-explanatory for some (country, sector) but others (e.g., ai_use_cases) lack context. The description fails to compensate for the sparse 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 the tool performs 'Company compliance API / regulatory applicability / compliance preflight' – a clear verb-resource combination. It distinguishes from sibling tools (which are specific checks like AI Act or VAT) by positioning this as a general screening. However, it doesn't explicitly name alternatives or contrast with them, so it's not a 5.

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

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

No explicit guidance on when to use this vs. the more specific sibling tools (e.g., check_ai_act_applicability or screen_ofac). The phrase 'preflight' implies a first-pass screening, but there is no 'use this when...' or 'for specific regulations use...' context. This leaves the agent to infer applicability.

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 read-only and non-destructive. Description adds that it returns a specific value (NO_POTENTIAL_MATCH or potential matches) and clarifies it is not a legal clearance, which provides transparency beyond 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?

Description is concise, contains only essential information: purpose, return type, and a caveat. No unnecessary 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?

Tool is simple; description covers purpose, return type, and a caveat. It is complete enough for understanding usage. No output schema is defined, but the return type is mentioned in the description.

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?

Input schema already provides descriptions for each parameter. Description does not add additional meaning or constraints for the parameters, so it adds no value beyond 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?

Description clearly states it's an OFAC sanctions screening API/check, and specifies return value and that it's not legal clearance. Purpose is clear and distinguishing from siblings by focusing on OFAC.

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?

Description does not provide explicit guidance on when to use this tool versus alternatives like check_ai_act_applicability or validate_eu_vat. It only describes what it does, so usage guidelines are lacking.

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, covering the safety profile. The description adds context that it is an 'Official European Commission' API, implying authoritative and reliable, but does not disclose additional behavioral details such as rate limits, error handling, or response specifics. With annotations this strong, a 3 is appropriate as the description adds minimal extra 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?

The description is a single, concise sentence: 'VAT validation API / VIES API. Official European Commission EU VAT check.' It is front-loaded with the core purpose and contains zero filler. Every word earns its place.

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

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

Given the tool's simplicity (2 well-documented parameters), the presence of an output schema, and strong annotations, the description is complete enough. It identifies the authoritative source (European Commission/VIES) and the purpose. The output schema covers return values, and annotations cover safety, so no further contextual information is necessary.

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 full descriptions for both parameters (vat_number, country_code) with schema coverage at 100%. The description does not add any additional meaning beyond what the schema already states, so it meets the baseline of 3 but does not exceed 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 it is a VAT validation API, specifically the VIES API from the European Commission. It specifies the resource (EU VAT check) and the action (validation), effectively distinguishing it from sibling tools that deal with AI act applicability, compliance preflight, OFAC screening, and legal entity verification, which are unrelated to VAT validation.

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 usage for EU VAT validation ('Official European Commission EU VAT check'), but does not explicitly state when to use it vs alternatives or provide exclusions. Since the sibling tools are unrelated to VAT, the need for explicit alternatives is low, but the description still lacks explicit guidance on when to invoke this tool.

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, openWorldHint, idempotentHint, and destructiveHint=false. The description adds useful context that this is an external API lookup against GLEIF, implying reliance on an external data source, which is beyond the annotations. No contradiction with 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?

The description is two concise sentences, front-loaded with the core purpose ('LEI lookup API / legal entity verification against GLEIF') and followed by the use case. No unnecessary words 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?

The description and schema cover the tool's purpose and parameters well, and an output schema exists. However, all parameters are optional but the description does not clarify that at least one identifier (LEI or company_name) is expected, and the relationship between parameters is implied only via schema hints. This leaves a small but important 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?

Schema description coverage is 100%, with clear descriptions for each parameter ('20-character LEI', 'Optional ISO country filter', 'Legal name if LEI is unknown'). The description itself adds no extra parameter semantics, so 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 'LEI lookup API / legal entity verification against GLEIF', identifying the specific resource and action. This distinguishes it from sibling tools like screen_ofac (sanctions) and validate_eu_vat (VAT), which serve different verification purposes.

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 a clear use case: 'Counterparty screening for onboarding and KYC workflows.' It does not explicitly exclude other tools or name alternatives, but the context is sufficiently clear for an agent to understand when this tool is appropriate.

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