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

Goes well beyond the annotations (which only say idempotent, non-destructive, open-world): discloses the registre:write scope, the required Bearer API key, the 24 h Idempotency-Key retention with stored-answer replay, and a precise billing model ($0.99/doc on live keys, free on test keys and 4xx/5xx, plus the Registre's own $1.50 fee). These are exactly the cost and auth facts an agent needs before triggering a paid 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?

The core operation and next step are front-loaded, but the description is roughly doubled by verbatim English/French duplication, making it long and repetitive to parse. The billing and fee sentences are useful but add further bulk to a three-parameter write tool.

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 compensates by telling the agent what comes back (job_id) and what to do next (poll job_get). Auth, scope, idempotency, and the full cost breakdown are all present, leaving nothing material an agent needs before calling it.

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 baseline is 3, but the description adds real meaning the schema lacks: idempotency_key is transmitted as the Idempotency-Key header, retained 24 h, and a same-key retry returns the stored answer. It also clarifies that rf_account_id defaults to the organization's own Registre account, which the schema states only tersely.

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 and resource ('Queues an index of immovables for one lot') plus the underlying route and the exact account it runs against. It also names the follow-up tool (job_get), so an agent can distinguish it from read tools like lot_get or document_get without opening the 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 a clear workflow: call this, receive job_id, then poll job_get. It does not address when to use this versus alternatives such as lot_resolve or plan_get, nor any preconditions like resolving a lot first, 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.