agosint

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

Annotations already cover the safety profile (readOnly, openWorld, non-destructive), so the bar is lower. The description earns credit by adding non-obvious behavior: billing semantics ('not charged when the site cannot be tied to one company'), that LEI lookups also return parent entities, and that name lookups return a short candidate list.

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?

Purpose is front-loaded, followed by coverage and then a compact 'Use when' clause; no sentence is wasted. The register list is dense but informative rather than 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 six-parameter open-world lookup with rich schema descriptions and no output schema, the definition covers scope, country-specific register behavior (CZ/NO/GB/US native vs. GLEIF fallback), and cost nuance. It could still say more about multi-country resolution or failure modes, but nothing required to invoke it correctly 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 fully documented with format constraints (patterns, max lengths, exactly-one-of rule). The description only restates the input modes collectively ('by registration number, name and country, VAT number, LEI or website') without adding syntax or precedence detail, so the baseline 3 applies.

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

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

States a concrete verb+resource ('Business registry lookup: company identity and legal entity enrichment as structured JSON') and enumerates the exact register coverage (CZ, NO, GB, FR, FI, US SEC, LEI). It never explicitly distinguishes itself from the 'company-de' sibling, so an agent must infer that Germany lives elsewhere — a real but minor gap.

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 one qualifying condition, 'Use when: you need the official identity of one company,' which implies the single-entity scope. It names no alternatives (company-de, due-diligence, verify, sanctions) and no when-not case, so routing between the many siblings is left 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, non-destructive, openWorld, non-idempotent), so the description correctly spends its words elsewhere: it discloses approximate latency ('about a minute') and the payment-chain restriction. It does not describe pagination or how `limit` billing interacts with returned records, which is a minor remaining gap.

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 resource and payload before the practical constraints. Every clause earns its place. The clipped 'Not offered on Solana: pay on Base or Polygon' is slightly terse but effective.

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 ten parameters and no output schema, the description usefully doubles as a summary of the returned record and warns about cost/latency before the agent commits. It compensates well for the missing output schema, though it says nothing about what an empty or no-match result looks like.

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 enums and defaults documented inline, so the schema fully carries parameter meaning. The description's field list describes the returned record rather than the inputs and adds no syntax or matching nuance. 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?

Names a specific resource (German commercial register / Handelsregister) and enumerates exactly what the record contains — court, number, legal form, status, seat, capital, representation rules, officers, history. The jurisdictional scoping ('the company is German') implicitly separates it from the generic `company` sibling, but it never names that sibling outright.

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

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

Explicit trigger condition: 'Use when: the company is German.' It also adds a concrete payment constraint ('Not offered on Solana: pay on Base or Polygon'), which prevents a failed call. It stops short of naming the alternative tool to use for non-German companies, so routing is only half-specified.

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, non-destructive, openWorld), so the description's job is to add operational context — which it does by disclosing the external data sources consulted (RDAP/WHOIS, DNS, TLS) and by signalling best-effort behavior with 'when it can be identified', implying some fields may be absent. It does not mention latency, rate limits, or handling of partially resolvable domains.

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?

Front-loaded with the resource and its scope, followed by a compact usage clause — two sentences, no filler. The long enumeration of record types is dense but each item is meaningful and justified for a tool whose whole value is the breadth of its lookup.

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 compensates by enumerating the categories of data returned, and annotations carry the safety profile. It is a single-parameter, read-only lookup, so remaining gaps (response shape, how missing data is represented, behavior on malformed input) are minor.

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 defines the single 'domain' parameter precisely (public domain name, IDN accepted, no URL/port/IP, maxLength 253). The description adds no parameter-level detail beyond the schema, so the baseline of 3 applies — nothing is lost, but nothing is added either.

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 resource and enumerates exactly what intelligence it returns (age/expiry, registrar, DNS record types, SPF/DMARC/MTA-STS, DNSSEC, TLS, hosting, company). It also implicitly separates itself from the sibling 'company' and 'network' tools by scoping itself to a single domain and treating the owning company as a conditional extra rather than the primary subject.

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

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

It gives an explicit 'Use when:' clause covering the two core scenarios — judging legitimacy of a domain/link/email sender, and auditing mail configuration. That is clear triggering context, but it names no alternatives or when-not conditions (e.g. use 'company' for org-level profiles, or what to do with an IP address instead of a domain).

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 read-only, open-world, non-destructive, non-idempotent profile. The description adds value beyond them by disclosing the cost behavior ("the call is not charged when it cannot be" identify the entity) and the signed pass/warn/fail output framing, though it omits rate limits or latency 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?

Two sentences, front-loaded with the capability, then the inputs, then the outputs and the usage trigger. No filler, and it reads as a compact decision aid.

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?

Despite no output schema and an open-world, multi-section operation, the description enumerates what is returned (legal entity, LEI and parents, VAT validity, sanctions screen of company and officers, domain age/mail/TLS, signed checks with sources) and notes the default include set, so an agent has enough to act correctly.

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

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

Schema description coverage is 100%, so every parameter is already documented, and the description only restates the input modes (name+country, registry number, VAT, LEI, domain) and the sections returned. The "send exactly one of" constraint lives in the schema, so the description adds little semantic value beyond 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 names a specific capability (company due diligence / KYB, vendor and supplier checks) and frames it as an aggregate that returns registry, LEI, VAT, sanctions and domain data. This clearly distinguishes it from the narrower siblings sanctions, vat, company and 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?

It gives an explicit when-to-use trigger: "Use when you must decide whether to trust an unknown company." However, it never states when to prefer the narrower sibling tools (sanctions, vat, domain) over this broader call, so the routing guidance is present but incomplete.

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

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

Beyond the annotations (which only say it is a non-destructive, non-idempotent write), the description discloses that it is free, requires no payment or account, is read by a real person, and is rate-limited to a few messages per hour. Rate limiting, cost, auth requirements and human review are exactly the behavioral traits an agent needs and none are in the structured fields.

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 opens with the most decision-relevant fact ('Free.'), then the action, then the practical constraints, in roughly 40 words with no filler or repetition. Front-loaded and every clause earns its place.

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

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

For a single-message submission tool with no output schema, the description covers cost, auth, human handling and rate limits, which is most of what is needed. It does not say whether a confirmation or ticket reference is returned, a minor omission given there is no output schema to rely on.

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 a high 75%, so the schema already documents route, contact and message. The description adds only loose mapping ('a bug, an idea or a thanks' to kind, 'what worked/failed/miss' to message) and says nothing that clarifies the route or contact parameters, 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 states a specific action with a clear target audience: send a message to the people who run the service, covering a bug, an idea or a thanks. That is far more concrete than the bare name 'feedback' and cannot be confused with the data-lookup siblings (company, domain, sanctions), though it never names or contrasts them explicitly, which is what a 5 requires.

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

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

It gives clear context for when to use it: to report what worked, what failed, or what you miss, with bug/idea/praise categories that map onto the kind enum. There is no explicit when-not-to-use or routing to an alternative channel (e.g. docs, support), so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description's field list is effectively return-value disclosure (valuable since there is no output schema), but it says nothing about rate limits, lookup latency, or why idempotentHint is false for a read 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 sentences, zero filler, with the capability front-loaded and the usage trigger immediately after. Every clause earns its place.

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

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

With no output schema, the description usefully previews the returned fields, and annotations cover the safety profile. The only real gap is that neither the description nor the schema explains behavior when both parameters are supplied or when neither is.

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

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

Schema coverage is 100% and both parameters are self-documenting with format examples. The description implies the two inputs are alternative query modes but never states whether ip and asn are mutually exclusive or which is required, adding little 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?

States a specific verb+resource ('IP address or AS number lookup') and enumerates the returned data (holder, announced prefixes, origin AS, country, RPKI status, abuse contact). This clearly separates it from siblings like domain, company, or sanctions lookups.

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?

'Use when: you need to know who runs an IP address or network' gives a clear trigger condition. It stops short of naming when NOT to use it or pointing to a sibling (e.g. domain) for hostname-based questions.

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 establish readOnly/no-destruction, so the safety profile is largely covered. The description adds genuinely useful behavior: it is free of charge, it caps results at three matching companies with named fields, it validates VAT format and check digit, it checks domain resolution and mail servers, and it returns the price. Missing pieces are whether it consumes quota or rate-limits.

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 sentences, with the core purpose front-loaded before the enumeration of what is checked. The list of checks is long but each clause earns its place by telling the agent what a preview will surface.

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 carries the burden of describing returns and it does so concretely (company fields, VAT validity, domain resolution, price). Combined with the annotations covering the safety profile and the schema documenting inputs, an agent has enough 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?

Schema description coverage is 100%, so both parameters are already documented, which sets the baseline at 3. The description's route-specific detail (company, VAT, domain behavior) adds flavor about what each route previews, but it does not clarify the nested 'input' body beyond what the schema says.

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 verb+resource: a free dry-run of a request against a route, returning whether it can be answered and what it would return. It implicitly distinguishes itself from the paid sibling routes (company, vat, domain) by framing itself as the pre-payment check, though it never names a sibling explicitly.

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

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

It gives an explicit trigger: 'Use when: you are not sure the paid call will find the right subject.' That tells the agent when to reach for preview instead of a paid route. It stops short of naming the alternative tools or stating when preview is unnecessary (e.g. when the subject is already known).

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, destructiveHint=false and openWorldHint=true, so the safety bar is low; the description still adds real value by disclosing fuzzy matching, the score scale, and the explicit non-compliance disclaimer. It does not mention latency, list-freshness or rate limits, which a screening tool could reasonably be expected to flag.

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?

Front-loaded with the screening scope and sources, then inputs, then usage and caveat. It is somewhat dense and long but every sentence carries operational information; no filler or restatement of the 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 7-parameter tool with no output schema, the description helpfully sketches the return shape (score per hit, programme, list publication date) and the accepted subject types. It omits the fact that all parameters are optional but at least one of name/wallet is effectively needed, and says nothing about pagination or result caps.

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 kinds, lists, country, threshold and birth_date semantics. The description loosely reinforces the input shape ('optionally with country or birth date') but adds no syntax or interpretation beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb+resource (sanctions screening) and names the exact data sources (OFAC SDN, EU consolidated, UK) plus what the tool returns (score per hit, programme, publication date). It also enumerates the two subject types (name vs. wallet address), which cleanly separates it from siblings like company, vat and 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?

Gives explicit when-to-use context: 'screening a counterparty, supplier, customer or wallet before a payment or onboarding', plus a scope caveat ('screening aid, not a compliance determination'). It does not name an alternative sibling (e.g., due-diligence) or state when NOT to use it, so it falls short of a 5.

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

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

Annotations already declare readOnly, non-destructive, open-world behavior, lowering the burden. The description still adds real context beyond them: it discloses the returned fields, explains that the consultation number serves as audit evidence, and flags the behavioral exception that Norwegian numbers are checked against the Norwegian VAT register rather than VIES.

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?

Front-loads the core action and the authoritative source, then folds outputs and the Norwegian exception into a single dense sentence before the use-when clause. Well structured, though the enumeration of return fields is slightly list-heavy.

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 cover the essentials: validity verdict, name and address, name-match result, and consultation number. It does not mention error conditions (invalid format, service unavailable) or rate limits on the external VIES call, which would round it out.

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 parameters are already documented in the schema, including the country-prefix format and the not_checked/match/partial/mismatch outcomes. The description restates the optional name check and requester-VAT consultation number but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb (validate) and resource (EU VAT number) against a named authority (VIES), and enumerates what comes back: valid/invalid status, registered name and address, name-match check, and consultation number. An agent can immediately tell this apart from siblings like company, company-de, sanctions, and verify.

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 explicit trigger scenarios: 'Use when: onboarding an EU supplier or customer, or before paying an invoice.' That is clear context for selection, but it names no alternatives or when-not conditions (e.g. non-EU entities, or when full company data is needed versus a pure VAT check).

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only the cost note ('Free:') and no behavioral context such as what a failed verification means, whether verification depends on external state (idempotentHint=false is unexplained), or what the caller receives. With annotations carrying the safety burden, this is a below-average supplement.

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 short sentence with the cost qualifier front-loaded and no filler. Nothing in it is redundant or wasteful.

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 verification tool with a fully described schema, the definition is barely adequate: with no output schema, the description should explain what verification returns (valid/invalid, failure reasons), which it omits. The schema itself is clear about input shape, which partially 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?

There is a single parameter and schema description coverage is 100%, so the schema already explains that the record must be one exactly as delivered with its receipt included. The description adds nothing about the parameter. Baseline 3 applies when the schema does all the work.

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 (verify) and a specific resource (the signature and content hash of an agosint answer), so the agent knows exactly what operation is performed. It does not compare itself to any sibling tool, but none of the siblings (company, domain, sanctions, etc.) overlap with verification, so disambiguation is not really at stake.

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?

There is no guidance on when to invoke this tool versus alternatives, nor on prerequisites (e.g. call it after receiving an answer). The only contextual cue is 'Free:', which hints at cost rather than usage conditions.

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