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

Beyond the read-only and idempotent annotations, the description adds useful domain behavior: the award differs if the employee resigns, part-years are included, and Articles 84–85 of Saudi Labour Law govern the result. It does not explain calculation assumptions or output structure in detail, but with annotations present this is a meaningful disclosure.

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 short and front-loaded with an illustrative example followed by the legal basis and scope. The web page URL is extra but not disruptive; every sentence carries some relevant information.

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 no output schema, the example communicates the expected result shape (a SAR award amount that changes on resignation). The description also names the legal basis and notes part-year inclusion, though it could explain return values or calculation assumptions more fully.

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 the schema already documents all four parameters. The description's example shows how wage, duration, and resignation affect the result, adding some semantic context for the 'reason' parameter, but it does not provide additional parameter syntax or meaning beyond what the schema states.

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 conveys that this computes a Saudi end-of-service award under Labour Law Articles 84–85, and the example implies a calculator for gratuity/severance. It clearly identifies the jurisdiction, which distinguishes it from sibling country-specific tools, but it does not name an alternative sibling or state its purpose as a direct verb-first statement.

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 Saudi law reference and the resignation example, giving an agent enough context to infer this is for Saudi end-of-service cases. However, it does not explicitly say when to use this versus egypt_end_of_service_calculator, uae_gratuity_calculator, or gcc_gratuity_calculator, nor does it give exclusions or prerequisites.

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