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 discloses constraints (max 1000 rows, cost per line, plan requirement) and the three input modes, but does not state whether the operation is read-only or has side effects, leaving some behavioral ambiguity.

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 paragraph of four sentences, directly stating the purpose, constraints, use case, and input modes. It is concise and front-loaded, with no redundant information, though a bulleted list could improve 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?

Given the complexity (3 parameters, no output schema, no annotations), the description covers inputs and constraints but does not detail the output structure or how to interpret the results. It mentions the types of returned data but lacks specificity, leaving agents potentially uncertain about the response format.

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 0% description coverage, so the description must compensate. It explains the three input modes for rows and the role of 'ref'. However, it does not describe 'radius_m' and 'max_matches' beyond what the schema provides (defaults and limits), missing an opportunity to clarify their semantic impact.

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 cross-references a user-provided list with French permits to retrieve multiple data points (proximity permits, opportunity score, risks, zoning, cadastre). It specifies the max list size, use case, and distinguishes from sibling tools that focus on single aspects.

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 identifies the use case (enriching prospect/asset lists) and explains input modes. However, it does not explicitly tell when not to use this tool or mention alternative tools for specific data types, though the context of sibling tools implies differentiation.

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 full burden. It discloses the rolling window and access restriction, but omits behavior details such as what 'top' means, whether permits must exist, output format, or data freshness.

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 concise with three sentences front-loaded with action. The second sentence adds value by explaining the purpose, and the third states an important restriction. No waste.

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 4 parameters, no output schema, and no annotations, the description is too minimal. It does not explain what the tool returns, the meaning of 'top,' or how parameters like limit and min_year affect results.

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 only 25% (type_local has a description). The description adds no meaning for limit or min_year, and only implies that num_pa is a permit number. It fails to compensate for the 75% schema coverage gap.

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 returns top neighboring DVF transactions for a permit, with a rolling 5-year window, and explains its purpose for property value estimation. However, it lacks explicit differentiation from sibling tools like get_permit_details.

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 only mentions a plan restriction (Plan Pro+ uniquement) but provides no guidance on when to use this tool versus alternatives like search_permits or get_existing_buildings.

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 full burden. It discloses technical behavior (pg_trgm, case/accent/typo insensitivity), cost (1 quota unit), and geo scope respect. However, it omits whether the operation is read-only (though implied), what the response contains, or pagination details. The disclosed info is useful but incomplete.

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 concise (few sentences) with a clear front-loaded purpose. Every sentence adds value: purpose, technical details, use case, cost, example. No fluff 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?

Given the lack of output schema, the description covers tool purpose, behavior, use case, cost, and geo-scoping. It lacks a description of the return format or error behavior, which would be helpful. Overall, it is mostly complete 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 67% (2/3 params have descriptions). The description adds value beyond schema for q by clarifying fuzzy, insensitive, typo-tolerant behavior and giving examples. For dep_code, schema description is sufficient; description adds nothing. For limit, neither schema nor description provides explanation, so a gap remains.

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 a specific verb+resource: 'Recherche fuzzy par texte libre sur les adresses'. It defines the scope (street, city, lieudit) and gives a concrete use case (finding permits via approximate address). The examples further clarify intent, distinguishing it from sibling tools like search_permits.

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 clear context by stating 'Idéal pour trouver un permis quand on connaît l'adresse approximative mais pas le code postal ou commune INSEE précis'. This tells when to use it, but it does not explicitly mention when not to or name alternative siblings. The guidance is helpful but lacks exclusions.

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 burden. It discloses the output (nb_batiments, breakdown, flag, details), data source, plan restriction (Pro+), cost (1 unit), and error behavior (404). It does not mention mutation or safety, but as a read tool, this is sufficient.

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 moderately long but each sentence provides distinct value (purpose, use case, output details, source, limitations, error). It is front-loaded with the core purpose.

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 no output schema, the description thoroughly explains the return values, including counts, flag, and individual details. It also covers source, plan restriction, cost, and error case, making it complete for agent invocation.

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% for the single parameter 'num_pa', which is already described in the schema as 'Identifiant Sitadel unique'. The description adds no additional semantic details beyond the schema, 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 explicitly states the tool lists existing buildings on a parcel for a permit, with specific verb 'Liste' and resource 'bâtiments cadastraux déjà construits'. It distinguishes from siblings by detailing a critical use case (marchand de biens) and output specifics.

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 clear context for when to use the tool (e.g., assessing if a parcel is bare or built) and mentions a specific use case. However, it does not explicitly state when not to use or name alternatives among 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?

With no annotations provided, the description carries full burden. It describes the output (score, tier, breakdown) but does not disclose side effects, prerequisites (beyond plan), error conditions, or whether the operation is read-only. The description gives moderate behavioral context but lacks completeness.

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 concise sentence, front-loaded with the main action and output. It avoids redundancy but could be slightly better structured with separate lines for output and condition.

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 no output schema and one parameter, the description provides key output details but omits what the '7 signaux' are, how errors are handled, and any dependencies (e.g., permit must exist). It is adequate but not fully 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 0%, so the description must compensate. It mentions the parameter is for a permit ('pour un permis') but does not explain the parameter name (num_pa), format, or example. Minimal additional 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 clearly states the tool calculates a specific score (Score Opportunité Marchand de Biens v0.1) for a permit, with output details (0-100, tier, breakdown). It also identifies the plan restriction, distinguishing it from sibling tools like get_permit_details or search_permits.

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 states 'Plan Pro+ uniquement', providing a clear condition for use. However, it does not mention when not to use this tool or suggest alternatives, though the plan restriction itself guides appropriate usage.

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?

Discloses return format, data source, access restriction, and error condition (404). No annotations provided, so description covers key behavioral traits adequately.

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?

Extremely concise: 2-3 sentences covering purpose, output, usage context, and error. No fluff, front-loaded with main output.

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 one-parameter tool with no output schema, the description covers what is returned, data source, error condition, and access. Lacks mention of response size or rate limits but acceptable.

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 only parameter has a clear description in the schema; the tool description adds no further semantic detail beyond what's already there. Baseline 3 for high schema 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 clearly states that it returns precise geometry of the cadastre parcel as GeoJSON Polygon with surface area and Etalab ID. It distinguishes from siblings by contrasting with address-based lat/lng.

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?

Mentions the tool is for 'Plan Pro+ uniquement' and a specific 404 case, implying when to use and limitations. Could be more explicit about alternatives.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It does not mention error handling, rate limits, authentication, or behavior on invalid input, and only vaguely hints at cost with 'Plan Free OK'.

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 front-loaded purpose. The first sentence is slightly long but information-dense. No waste.

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 single-parameter tool, the description adequately lists the types of details returned. The meaning of 'Plan Free OK' is ambiguous, but overall completeness is sufficient for basic 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% with a clear description of num_pa. The description adds a list of returned fields but does not enhance understanding of the parameter beyond what the schema already 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 tool retrieves all details of a permit using a specific identifier (num_pa) and lists the types of details returned. It is specific about verb and resource but could better differentiate from sibling get_permit_full_view.

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 guidance on when to use this tool versus siblings like get_permit_full_view or search_permits. The phrase 'Plan Free OK' hints at cost but does not clarify usage 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?

No annotations provided, so description carries full burden. Discloses cost (6 units for Pro+, 1 for Free/Explorer), failure behavior (null fields, errors in fetch_errors), and typical latency (5-7s).

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 a single paragraph but packs significant detail efficiently. Front-loaded with purpose, though slightly lengthy.

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?

No output schema, so description should explain return values. It lists sub-features but does not detail the JSON structure or fields. Missing structure for a complex combined 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?

Input schema has 100% coverage with description for the single parameter, so baseline 3 applies. The description adds no extra parameter insights beyond what the schema already 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?

Description clearly states it provides a full 360 view of a permit in one call, combining detail, sirene, dvf, score, zoning, risks. It distinguishes from siblings by explicitly mentioning it replaces 6 separate 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?

Explicitly tells when to use: when you want everything at once instead of 6 separate tools. Also mentions cost implications and plan limitations (Free/Explorer vs Pro+).

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 full burden. It describes the output (zoning types, constructible boolean, legal reason) and source, but does not disclose potential side effects, authentication needs, or error handling. The tool is clearly a read-only query, but lacks details on behavior under failure.

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 sentences: the first delivers the core functionality and output details, the second adds source and restriction. No wasted words, and key 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?

For a tool with one parameter, no annotations, and no output schema, the description covers the output structure (zoning types, boolean, reason) and source. It lacks error scenarios or response format specifics, but is mostly complete for a simple query 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 0% and the description does not explicitly explain the 'num_pa' parameter. It implies it is the permit number ('au point géocodé du permis'), but no format or example is provided. The description adds minimal value 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 clearly states it returns zoning information (PLU) at the geocoded point of the permit, listing specific zoning types (UA/UB, AU, A, N), a boolean constructibility verdict, and legal reason. It distinguishes itself from sibling tools like get_risks or get_existing_buildings by focusing specifically on zoning.

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 limits usage to 'Plan Pro+ uniquement', providing a clear condition for when to use this tool. It does not mention when not to use it or suggest alternatives, but the restriction is helpful 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?

With no annotations, the description must disclose behavioral traits but only mentions the data source (Géorisques BRGM) and a usage restriction. It does not specify that this is a read-only operation, potential rate limits, caching behavior, or what happens if the commune has no data. The aggregate score range is given but tier meaning is unclear.

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 concise at 25 words but mixes French terms without translation, potentially hindering clarity. It front-loads key information but lacks clear structure (e.g., separate lines for different details). Not verbose but not optimally organized.

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 has one required parameter, no output schema, and no annotations, the description is insufficient. It lacks details on output format (beyond score and tier), error handling, how to interpret the tier, and what happens if the permit number is invalid. Agents may not reliably know how to use 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?

The schema has one required parameter 'num_pa' (string) with 0% description coverage. The tool description does not explain what 'num_pa' represents (e.g., permit number or parcel identifier), leaving the agent to guess from sibling tools. No additional semantic context is provided.

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 the tool retrieves natural and technological risks (inondation, seisme, argile, ICPE) for the municipality of a permit, including an aggregate score (0-100) and tier. It identifies the specific resource and action, distinguishing it from sibling tools like get_permit_details or get_mdb_score, which cover different data.

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 mentions 'Plan Pro+ uniquement' (only for Pro+ plan) as a constraint, but lacks explicit guidance on when to use this tool versus alternatives. No instructions on prerequisites, when not to use, or comparison 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 provided, so description carries full burden. It discloses that certain filters have quota costs and are reserved for higher plans, which is good. However, it lacks details on pagination, error responses, or rate limits, and doesn't clarify that 'page' implies no offset parameter (only limit).

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 tight sentences, front-loaded with purpose. The first sentence lists filters efficiently. Could be structured with bullet points for readability, but overall no wasted 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?

Given 14 complex parameters, no output schema, and no annotations, description covers plan tiers, cost implications, and return type ('page de permits'). Missing details: pagination mechanism, return field list, error handling, and rate limits. However, sibling tools like get_permit_details fill the gap for detailed views, making this adequate for a search endpoint.

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 86% (12 of 14 params have descriptions), so baseline is 3. The description adds minimal value beyond schema: it states 'filtres combinables' and 'infos de base', but doesn't elaborate on parameter usage or constraints beyond what's in 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 searches for French building permits with combinable filters and returns basic info. The verb 'Recherche' and resource 'permis de construire' are specific. While it distinguishes from siblings like get_permit_details by its listing nature, it doesn't explicitly contrast with them.

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 implies usage for filtered searches but provides no explicit when-to-use or alternatives. It mentions plan restrictions (e.g., 'Free OK', 'réservé aux plans Pro+') which gives some context, but no guidance on when to choose this over sibling tools like bulk_enrich_list or find_dvf_neighbors.

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