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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered by structured data, and the description correctly stays consistent with a pure calculation. It adds that the tool is an 'estimate' producing monthly and yearly figures, which is useful output context given there is no output schema, but it does not disclose the calculation model, how currency affects results, or how the two rate methods are combined.

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?

A single well-packed sentence with the verb and output scope front-loaded, so an agent can decide quickly. The closing clause about cost per engagement adds length without adding a usable input, which keeps it from a 5.

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?

With eight parameters, two required, no output schema and only lightweight annotations, the description does a fair job: it names the rate bases and says the result is monthly and yearly income. It leaves the agent guessing about currency defaulting behaviour, how the two rate modes interact, and how average engagements factor in, which is a real gap for a calculator tool.

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 100%, so every one of the eight parameters is already documented, including the either/or relationship between rate_per_post and rate_per_1000_followers. The description mirrors that at a high level but adds no syntax, defaults, or unit detail beyond the schema — baseline 3 applies. The mention of 'cost per engagement' is not backed by any parameter, which is a minor source of confusion rather than added meaning.

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 opens with a specific verb and resource ('Estimates monthly and yearly Instagram brand-deal income') and enumerates the rate bases (per post, per story, per 1,000 followers), which makes it distinguishable from siblings like youtube_earnings or ad_budget_planner. It stops short of naming the sibling alternative, and the trailing phrase 'the cost per engagement a brand pays' points at an input that does not exist in the schema, slightly muddying the scope.

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?

There is no statement of when to choose this over alternatives (notably youtube_earnings, which shares the earnings-calculator role), and no prerequisites or exclusions. The use case is only implied by the phrase 'brand-deal income'.

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