definir_contrato

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

With no annotations at all, the description carries the behavioral burden and does a fair job: it discloses that only supplied fields are mutated (partial update), that null is a meaningful value for several fields, and that the data feeds derived dashboard computations (cliente ativo demais, renovação próxima, custo por entrega, acima-do-contrato). It stops short of stating reversibility, required permissions, or what a successful write returns, which matters for a mutation tool with zero annotation coverage.

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 with the purpose, then partial-update rule, then downstream effects, then the read alternative and the one non-obvious parameter — a sensible ordering with little filler. It runs dense with multiple clauses per sentence, and the dashboard-effects sentence is longer than it needs to be, but nothing is redundant.

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 7-parameter mutation tool with no annotations and no output schema, the description covers the essentials: what it writes, that writes are partial, how a key parameter is enforced downstream, and where to read the result. The remaining gap is the absence of any statement about the response, error behavior on an invalid grupo slug, or permission requirements.

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 71%, so the baseline is 3, and the description adds real meaning beyond the schema for the least obvious parameter: "acima dele o dashboard aponta acima-do-contrato" explains the consequence of limite_mensagens rather than just its format. It also glosses estado's enum values and the date format inline, though grupo is left entirely to the schema and null-vs-omitted semantics for fields like valorMensal are not spelled out.

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?

"Define o estado comercial de um chat" names a specific verb and resource, then enumerates exactly which fields constitute that state (estado, início, fim, valor mensal, nota, limite_mensagens). It explicitly distances itself from the sibling "dashboard" by declaring that tool as the read path, so an agent can route 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?

The definition gives a clear use case (setting commercial/billing state of a chat) and names the explicit alternative for reading: "Pra ler, use a tool dashboard." It also states the partial-update rule "Só os campos passados mudam," which tells the agent how to call it safely. Lacking is any statement of when NOT to use it (e.g., permissions, whether setting "sem" clears prior data instead of closing).

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