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

Beyond the annotations, the description reveals important behavioral details: nested objects merge rather than replace, and the tool 'does not read or write Brand Memory.' This adds meaningful side-effect context that the annotations alone do not convey, though it stops short of documenting error behavior or exact write semantics.

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 tightly written and front-loaded with the core behavior: 'Patch Brand DNA. Send only keys to change.' Every sentence adds value: the merge rule, the example keys, and the Brand Memory boundary. There is no filler or repetition.

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 single-parameter tool with a dynamic object field, the description provides sufficient structural examples and merge semantics to call the tool correctly. It also clarifies the key boundary with Brand Memory. The presence of an output schema means return-value documentation is not required, so no major information gap remains.

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 description coverage is 0%, so the description carries the burden of explaining the 'fields' parameter. It compensates well by listing concrete accept keys like tagline, overview, offer, product_map, and icp, plus their nested structure. It remains example-based rather than a complete schema, but it gives an agent enough to construct a valid payload.

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 states a specific action and resource: 'Patch Brand DNA.' It clearly distinguishes the tool from get_brand_dna by framing this as a write/update operation, and the emphasis on partial updates makes its function clear. It doesn't explicitly name sibling alternatives, but the intent is unambiguous.

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 useful invocation guidance: 'Send only keys to change' and explains that nested bags merge. However, it does not explicitly state when to use this tool over alternatives like get_brand_dna or clarify_brief, nor does it mention any exclusion conditions. Usage is implied rather than explicitly routed.

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