French Due Diligence

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

Annotations already establish readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds meaningful behavioral context beyond that: the verdicts are computed against current electricity rules for label estimation, DPE validity is reported, and it explicitly disclaims that this is information, not legal advice.

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 purpose and policy context are front-loaded in the first clause, followed by a short narrowing instruction and a disclaimer. The single dense sentence is information-rich without padding, though it is long enough that the output enumeration could have been split for readability.

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 and no annotations covering return values, the description compensates by enumerating the returned fields (DPE, rentability, rent-freeze status, ban date with year thresholds, validity, estimated label). No auth, rate-limit or error behavior is described, but for a read-only lookup that gap is 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 75% (address, surface and complement are documented; floor is not), so the schema does most of the work. The description adds the useful framing that floor/surface/complement are narrowing filters, but contributes no format or semantic detail the schema lacks, which matches 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?

States a specific verb+resource (returns each dwelling's DPE and its rental verdict under the Climate and Resilience law) and enumerates uniquely scoped outputs — rentability, rent freeze, ban dates, validity, estimated label. This clearly separates it from the sibling get_dpe, which returns raw DPE data without a rental verdict.

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 names the context (a French postal address) and tells the agent how to narrow results with floor, surface or address complement, which implies usage. However, it never states when to prefer this over the sibling get_dpe, nor any exclusions or prerequisites.

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

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

Beyond the readOnlyHint/openWorldHint annotations, it discloses that the check is live, that name_matches is a consistency signal and explicitly not proof of ownership, and that vies.status 'unavailable' is an indeterminate result rather than an invalid one. These are exactly the behavioral caveats an agent needs to avoid misreporting results.

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 verb and scope are front-loaded and every sentence carries information, with no filler or restatement of the title. Sentences are long and parenthetically dense, which slightly hurts scannability.

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

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

With no output schema, the description carries the return-value burden and does so: it enumerates returned fields (name, address, company active, insolvency proceeding, name_matches, vies.status). An agent has enough to call the tool and interpret its result without further documentation.

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, but the description adds real meaning: requester_vat is explained as producing a consultation number that serves as proof of the check, not merely a lookup input. The accepted input forms (FR VAT, SIREN, SIRET) are already in 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 and resource: a live validity check of a French VAT number (or SIREN/SIRET VAT number) against VIES, crossed with the French registry. This is functionally distinct from siblings like get_company or validate_identifier, but no sibling is named, so it falls short of explicit differentiation.

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 operative guidance: pass requester_vat to obtain a VIES consultation number as proof, compare returned names to confirm ownership, and retry later when vies.status is 'unavailable'. It does not name or exclude any sibling tool, but the conditions for correct use are well covered.

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 and openWorldHint, so safety is covered; the description nonetheless adds what the agent gets back — an in_insolvency flag and latest BODACC court announcements — which is meaningful disclosure given there is no output schema. It omits error behavior for unknown/invalid SIRENs.

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 purpose and identifier, then the returned fields, then the use case — no filler. The field enumeration is long but earns its place because there is no output schema; it stays within two sentences.

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 read tool with no output schema, the description supplies the essential payload contents and the insolvency signal an agent needs. Remaining gaps (SIREN format, invalid-input behavior) are minor but real.

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 0% and the single parameter is undocumented in the schema, so the description carries the burden. It does state the key is a SIREN (a real semantic gain over a bare string), but it never gives the expected format/length or what happens on a malformed SIREN.

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: a French company profile keyed by SIREN, and enumerates the payload (legal name/form, activity, active/ceased, head office, officers, insolvency, BODACC). It does not explicitly contrast itself with siblings like get_establishment or search_companies, so an agent must infer the company-vs-establishment and lookup-vs-search distinction.

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

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

Gives a concrete usage frame ('can I do business with this company?'), which tells the agent the intended decision this tool feeds. It offers no explicit when-not conditions or named alternatives (e.g. use search_companies to find a SIREN first), so guidance is clear 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds genuine behavioral context beyond that: the ADEME dataset drops replaced DPEs, so lookups for superseded certificates will fail. It still doesn't say what happens on an unknown number (error vs empty).

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, no filler, and the key identifying detail (the number format) appears early. The opening sentence is slightly convoluted ('The dwelling of a French DPE ... by its ... number') but still readable.

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 read-only lookup with no output schema, the description covers the input format, the conceptual return (dwelling + rental verdict), and a data-availability caveat. Only the failure behavior for missing or replaced DPEs is left unstated.

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 0% and the single dpe_number property has no description, so the description must carry the parameter. It does: it specifies the 13-character format and gives a concrete example (2569E0160739C), which is exactly what an agent needs to construct a valid call.

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 (the dwelling of a French DPE) and the retrieval key (its 13-character number, with an example), and it positions itself against the sibling check_rental_compliance by saying it returns the same rental verdict. The verb is only implicit from the tool name, but an agent can still distinguish this tool from its siblings.

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

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

Usage is implied: use this when you already hold a 13-character DPE number and want the dwelling plus verdict. The reference to check_rental_compliance hints at a relationship but never states when to choose one over the other, and no prerequisites or exclusions are given.

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

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

Annotations declare readOnlyHint and openWorldHint, so the safety profile is covered. With no output schema, the description usefully discloses the returned fields (address, NAF, open/closed, head office) rather than just restating the annotations.

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

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

Two compact sentences, front-loaded with the resource and identifier before the use case. Nothing redundant, though the trailing phrase "open or closed, head office or not" is slightly clunky.

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 with annotations covering safety and no output schema, the description covers identity, returned fields, and use case adequately. Only parameter-level detail (SIRET format/handling of unknown SIRET) 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?

There is one parameter with 0% schema description coverage, so the description carries the burden. "By SIRET" identifies the key and its role, but adds no format, validation, or lookup-failure detail beyond what the schema type implies.

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

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

States a specific verb (get) and resource (one establishment of a French company) keyed by SIRET, and enumerates what is returned (address, NAF activity, open/closed, head office flag). It implicitly separates itself from get_company by scoping to a single establishment, though it never names that 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?

"Use it to check a supplier's or invoice's address" gives a concrete context for reaching for this tool. It offers no explicit when-not conditions or named alternatives, so it stops short of 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?

Annotations only cover readOnly/openWorld, but the description adds substantial behavioral context beyond them: the count is approximate and why (double-counting establishments, SIREN substring matches), suspect/aberrant amounts are excluded, amounts are buyer-declared ceilings excl. VAT and not spend/revenue, and page size is fixed at 20. These are exactly the caveats an agent needs to interpret results.

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

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

Dense but front-loaded: the primary noun phrase and returned fields lead, caveats follow. It is long and runs as a single block with semicolons rather than scannable structure, but nearly every clause carries informational weight.

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 full return-value burden and does so thoroughly: itemized fields, pagination order, and the company status fields (active, insolvency proceeding). Nothing essential for correct invocation or interpretation 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 75%, already documenting from/to ('Notified on or before/after') and page ('Page of 20 contracts'). The description largely restates those (notification dates, 20 per page) and adds nothing about the undocumented siren parameter, so it sits at the schema-driven baseline.

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

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

States a precise verb+resource: returns public contracts a French company won, sourced from DECP procurement data, with a concrete enumeration of what comes back (count, summed max amounts, first/latest notification, paginated contract list). An agent can distinguish this from get_company or get_establishment without opening any schema.

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

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

Gives clear selection context (this is the DECP public-procurement view rather than general company data) and an explicit narrowing instruction: 'Narrow with from and to (notification dates).' It does not, however, name a sibling alternative or state when NOT to use it, so it stops short of 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?

Annotations only declare readOnlyHint and openWorldHint; the description adds substantial behavioral context beyond that: the result taxonomy (clear/possible_match/strong_match), the rule that a match is a lead to verify rather than a decision, the DOB rule that rules out namesakes, and the SIREN/SIRET criterion that distinguishes strong from possible. That is exactly the interpretive guidance an agent needs.

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 register scope, then moves into result semantics and match-strength rules. It is dense and slightly long, but nearly every clause carries decision-relevant information rather than filler.

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

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

There is no output schema, and the description compensates fully by explaining the returned verdicts, the fields attached to each match (register entry, legal bases, official page), and the limits of the check. An agent can call and interpret this tool without further documentation.

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?

Only one parameter and schema coverage is 100%, so the schema fully documents the accepted identifier formats (SIREN/SIRET/FR VAT, spaces allowed). The description adds nothing about the input beyond what the schema already says, so baseline 3 applies.

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

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

States a specific verb (screens) and resource (a French company and its officers) against a named register (registre national des gels), with the scope of measures (UN, EU, French) made explicit. It is clearly distinguishable from siblings like check_vat or get_company, which do not perform sanction screening.

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 delimits coverage and explicitly names what is NOT covered (beneficial owners, OFAC/UK foreign lists, politically exposed persons), which is valuable exclusion guidance. It does not name a sibling alternative or state a trigger condition, so it stops short of full when/when-not 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds a real behavioral detail the annotations do not: the result is capped at 10 companies and includes only the SIREN, signalling this is a thin discovery call rather than a full retrieval.

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 with no filler; the primary capability comes first and the follow-up routing is compressed into a short closing clause. Every clause carries information.

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

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

With no output schema, the description must convey return behavior, and it does state the 10-result cap and the SIREN field. It omits pagination or narrowing advice when results hit the cap, which is the main remaining gap for a search tool.

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

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

Schema coverage is 50%, with department and postal_code undocumented in the schema. The description compensates by giving concrete department formats ('75, 2A, 971') and a NAF example ('10.71C'), which clarifies two of the four parameters beyond what the schema's patterns show on their own.

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 ('Finds French companies') plus the narrowing dimensions (department, postal code, NAF activity code). It also names the sibling get_company as the follow-up, so an agent can distinguish this search tool from the profile-fetching tool without opening either 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?

Explicitly frames this as a lookup step and routes the agent forward ('Use get_company next for the full profile'), which is genuine usage guidance. It stops short of stating when *not* to use it or how it differs from siblings like get_establishment or validate_identifier.

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 and openWorldHint, so safety is covered. The description adds real behavioral substance beyond that: it performs format checks, checksum verification, and an existence lookup against registered companies/establishments — the last of which explains why openWorldHint is set.

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, no filler. The capability and accepted formats are front-loaded, and the usage cue is a short trailing sentence 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 one-parameter, read-only validate tool with no output schema, the description covers inputs, checks performed, and usage timing. It never indicates the shape of the result (e.g., pass/fail plus matched entity), which is the only meaningful 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 coverage is 100% and the single param is documented, so the baseline is 3. The description goes further by pinning each accepted identifier type to its exact length (9, 14, FR+11), which is more actionable than the schema's generic min/max bounds.

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 verb (validates) and the exact resource universe (SIREN 9 digits, SIRET 14 digits, intra-EU VAT FR+11), then enumerates what is verified. This clearly separates it from siblings like get_company or get_establishment, which retrieve rather than validate.

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 it first when an identifier was typed by a person" gives an explicit triggering condition and positions the tool ahead of retrieval siblings. It stops short of naming the alternative to call once validation passes (e.g., get_company), so it is clear context without full routing.

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