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

Goes well beyond the annotations: discloses that idempotency_key is sent as the Idempotency-Key header with a 24h window and stored-answer replay, requires the caller's own Fonciq API key as a Bearer token, and details that creation is free while each pulled index costs 0,99 $ plus a third-party Registre fee of 1,50 $ that Fonciq does not collect. This is exactly the cost/auth/idempotency context an agent needs before a write.

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 and well-organized, but every sentence is duplicated verbatim in English and French, and the billing explanation is restated three times across the two halves. Roughly half the tokens are redundant for a monolingual reader.

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 burden of return behavior; it explains the async nature (index pulled later, delivered by webhook) and covers auth, cost and idempotency. It stops short of describing what the POST response contains or what the webhook payload 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 coverage is already 80%, so the baseline is 3; the description adds real value on top by explaining that idempotency_key becomes an HTTP header with 24h retention and that cadence means weekly or daily re-checks against a baseline snapshot. It does not clarify rf_account_id beyond the schema, keeping it from a 5.

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+resource (POST /v1/watches creating a scheduled re-check of a lot's index) and scopes it with cadence and webhook delivery. It implicitly distinguishes itself from one-shot siblings like registre_index_request by noting 'The Registre has no push feed', though it never names an alternative 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?

Usage context is only implied: the 'no push feed' remark suggests this is the polling alternative to ad-hoc index requests, and cadence weekly/daily hints at recurring need. There is no explicit 'use this when…, use registre_index_request when…' routing against the 13 siblings.

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