Edita um campo: rótulo, obrigatório, visível, posição, opções, indexação. Mudança de TIPO só é permitida se for um alargamento seguro (ex.: integer→float); mudança com perda é bloqueada (crie um campo novo e migre).
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| type | No | ||
| label | No | ||
| object | Yes | ||
| account | No | ||
| indexed | No | ||
| options | No | ||
| visible | No | ||
| position | No | ||
| required | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a mutating, non-read-only operation, and the description adds meaningful behavioral constraints beyond that: type changes are restricted to safe widening, and lossy changes are blocked. It does not cover all possible side effects or permissions, but it discloses the most important operation-specific rule.
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 description is compact and front-loaded: the first clause states the action and scope, followed by a list of editable attributes and a focused warning about type changes. Every sentence earns its place with no redundant filler.
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?
The description is reasonably complete for a mutation tool, especially with the type-change safety rule, but the tool has 10 parameters and no output schema. Missing semantics for required identifier parameters, the 'account' field, and any return/confirmation behavior leave gaps for an agent trying to invoke it correctly.
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 0% schema description coverage, the description carries the burden of explaining parameters. It maps several parameters (label, required, visible, position, options, indexed) and provides a type-change example, but it leaves the required 'object' and 'key' identifiers unexplained and does not clarify the 'account' or 'options' formats.
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 clearly states the tool edits a field and lists the editable attributes (label, required, visible, position, options, indexing), distinguishing it from sibling tools like crm_add_field and crm_remove_field. The verb 'Edita' plus the specific resource 'campo' makes the purpose explicit.
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 description gives practical guidance on when not to use the tool: type changes are only allowed for safe widening, and lossy changes are blocked with the advice to create a new field and migrate. It does not explicitly name alternative sibling tools, but the when-not-to-use logic is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.