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

readOnlyHint and idempotentHint already establish that this is a safe, repeatable computation, so the description owes little on the safety front. It does add genuine domain context via the Saudi example (allowances count toward the hourly wage), but it says nothing about the response shape or which parameters each rules mode consumes. The stated US support conflicts with the rules enum, which is a schema inconsistency rather than an annotation contradiction.

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 with little wasted text, though the trailing website URL is pure promotion and the leading example is a poor front-load for a purpose statement. The useful routing information, if any, is buried at the end.

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 12 parameters, three mutually exclusive rule regimes and no output schema, the description should explain which inputs each mode needs and what the result contains; instead it offers one illustrative number. An agent cannot tell from this text whether rate, multiplier, otNight or regular are relevant under uae versus ksa.

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 12 parameters is already documented in the schema, which sets the baseline at 3. The worked example (SAR 6,000 basic + SAR 3,000 allowances = SAR 50/hr) does concretely illustrate how basic and total interact under Saudi rules, adding modest value beyond 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?

The second sentence gives a concrete verb and resource ("Get UAE, Saudi and US overtime pay from your real salary"), but the description opens with a bare worked example rather than stating what the tool does. It also fails to distinguish itself from nearby siblings like salary_calculator, hours_calculator or gcc_gratuity_calculator, and it advertises "US" overtime although the rules enum only offers hourly/uae/ksa.

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 explicit when-to-use or when-not-to-use guidance, and no help choosing among the three rules modes (hourly vs uae vs ksa), which is the single most important decision an agent must make here. The only implied usage cue is the mention of country names in passing.

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