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

The description adds real value beyond annotations by disclosing that the call also creates or links a customer and contact, and that the assigned user and campaign rules may be notified — an external side effect that fits openWorldHint=true. It does not, however, say what happens on duplicate customers, whether the write is reversible, or what the response contains, and there is no output schema to compensate.

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?

Three short sentences, front-loaded with the "WRITE:" marker and the core action; every sentence carries information. The trailing endpoint path is marginal value but harmless.

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 9-parameter mutation tool with 6 required fields and no output schema, the description covers the action, the entity linkage, and the notification side effect well. It stops short of describing return payload or failure modes, which an agent would want for a write call.

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 78%, so the schema already documents nearly every parameter, including the optional account_code for existing customers and the lookup hints for campaign_code and recipient_username. The description only restates the create-or-link behavior for the account/contact fields, adding little syntax or format detail on top of the schema.

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 a specific verb and resource ("Create a sales opportunity in a campaign") and names the two related entities involved (customer, assigned user). It partially separates itself from getfly_create_account by noting the customer/contact are created or linked as a side effect, but it never explicitly says when to call create_account instead.

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 is implied by the create semantics; there are no explicit when-to-use/when-not conditions or named alternatives. The prerequisite lookups (campaign_code, recipient_username) appear only inside the schema descriptions, not the tool description.

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