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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the description's real contribution is disclosing a modelling assumption: conversion cost is a generic 700 €/m² and is an order of magnitude to be confirmed by a quote. That caveat meaningfully qualifies how the agent should present results. It stops short of describing data sources or resolution limits of the geographic lookup.

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 no filler; the domain case (office/hotel/retail) comes first and the cost caveat is correctly placed last as a qualifier. The interrogative phrasing is slightly indirect for a tool description but remains readable and 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 12-parameter, all-optional tool, the description leaves the agent unable to assemble a valid call: it does not say that a location (adresse/lat-lon/section+parcelle) plus destination_actuelle and surface_existante_m2 are what make the analysis meaningful, and it ignores the two operating modes. An output schema and safety annotations exist, so return values and permissions need not be covered, but input adequacy is a real 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?

With 12 parameters and only 50% schema description coverage, the description should compensate, but it says nothing about the individual inputs. Notably the 'mode' enum (redeveloppement vs batiment_existant) — directly relevant to a tool titled 'redéveloppement' — is never mentioned, nor is whether an address, coordinates, or parcel identifiers are the preferred locator, nor how valeur_actuelle_eur or surface_existante_m2 drive the bilan.

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 conveys a specific analytical purpose: testing whether an existing office building, hotel or retail property would be worth more redeveloped, via constructibility, new-use comparison and a marchand de biens balance sheet on an existing building. It clearly frames an existing-building analysis, but it never names or contrasts the close siblings toise_etude_reconversion, toise_development or toise_parcelles_potentiel, so an agent must infer the boundary.

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 by the framing ('sur un bâtiment existant', 'vaudrait-il plus reconverti'), which implicitly scopes it to standing buildings rather than vacant land or new development. There is no explicit when-to-use, when-not, or named alternative, and no statement of what inputs are needed before calling it.

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