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

Annotations only declare it is a non-readonly, non-destructive, open-world write; the description adds the genuinely non-obvious behavior — the dedup key (CPF + birth date, or name plus mobile/e-mail/birth date) and that the existing id is returned with nothing created. It also flags the LGPD constraint on health data. Return shape beyond patient_id and error modes are not covered.

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?

Four short sentences, all load-bearing: write semantics and return first, then the dedup rule, then the no_cpf flag, then the compliance caveat. The trailing 'POST /patient/create' is minor filler but costs nothing.

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 27-parameter write tool with no output schema, the description covers the essentials an agent needs: what is created, what is returned, and when nothing is created. It could say more about what happens to the optional fields on a dedup hit (are they merged or discarded), which is the main remaining ambiguity.

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; the description earns a bump by explaining how cpf, birth_date, mobile and email interact as identity keys, and by tying no_cpf to the ignore-cpf behavior. It still leaves most of the 27 optional fields (insurance, price table, address) to the schema alone.

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?

Opens with 'WRITE: registers a new patient and returns the patient_id' — a specific verb, resource, and outcome. This cleanly separates it from feegow_update_patient (mutates an existing record) and feegow_get_patient (read), and the dedup note explains why it may not actually create anything.

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 concrete operating context: it is the write path for new patients, set no_cpf=true when there is no CPF, and existing matches are returned instead of duplicated. It does not explicitly say 'use feegow_update_patient to change an existing patient', so the sibling routing is implied rather than stated.

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