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

Annotations already establish read-only, idempotent, closed-world, non-destructive behavior, so the safety profile needs no restating. The description adds two genuinely useful behavioral facts beyond that: results are scoped to currently active job postings (so the range reflects live listings, not a historical dataset), and the output is not financial advice. It says nothing about how sparse data or missing matches are handled, how many listings back the range, or the shape of the returned range.

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 core purpose, then the sibling alternative, then the disclaimer. No filler, no repetition of the title or annotations.

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?

The tool has three entirely undocumented optional parameters and no output schema, so the description is the only place an agent could learn how query/currency/location change the result — and it says nothing about them. The sibling routing and disclaimer are well handled, but the parameter behavior gap is the deciding factor for a tool whose whole value is a computed range.

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 0%, so the description must carry the parameter burden and it does not — query, currency and location are named only in the schema with no descriptions. The description implies results are derived from job matching and could hint that location/currency narrow or denominate that range, but it never states whether currency converts figures, whether location overrides the profile location, or what happens when all three are omitted (all are optional).

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?

"Basic salary range from matching active Jobiba jobs" names a concrete output (a salary range) and a concrete data source (currently active job listings), and explicitly contrasts with salary_research's fuller view. It stops short of defining what "matching" is matched against, but an agent can still tell this apart from the sibling.

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 routes the agent: take this tool for a basic range, use salary_research when percentiles, trends, experience curves, skill premiums or city breakdowns are needed. There is no explicit statement of when this tool should NOT be used (e.g. when evaluating a specific offer, where analyze_offer or salary_calculator may be better), so it is clear context rather than full routing.

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