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

Annotations already cover read-only, idempotent, non-destructive, closed-world. The description adds value beyond them: it discloses that GigNGo runs no background checks (an important trust limitation), spells out provenance semantics for each evidence type (e.g. 'filmed (clips our check says show the work, not who is in them)'), and constrains misuse for high-stakes decisions.

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?

Front-loaded with the core purpose and handle sourcing, then the evidence taxonomy. It is dense and somewhat long, but each clause carries information (provenance definitions, the no-background-checks caveat, the prohibited uses) rather than padding.

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 description compensates by describing the record's contents at the item level (evidence types and what each means), which is exactly what an agent needs to interpret the return value. Combined with the handle sourcing and the prohibited-use boundary, nothing material is missing.

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?

Only one parameter with 100% schema coverage, so the schema already documents 'handle' with an example. The description adds meaning by specifying where the handle comes from (search_local_workers / get_worker_profile), which the schema does not say, though it does not add format or fallback details.

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?

States a specific verb+resource ('Get a local's Work Record') and immediately defines what the record is ('evidence of their work, where every item says how GigNGo knows it'). It enumerates the evidence taxonomy, which distinguishes it from get_worker_profile and search_local_workers, both of which are named as feeders for the handle rather than as substitutes.

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?

Gives explicit when-to-use routing ('Use the slug from search_local_workers or get_worker_profile as the handle') and explicit when-NOT-to-use constraints ('Not for employment, credit, insurance or tenancy decisions'). The interpretation rule 'Weigh each evidence type separately; never reduce the record to one score' is an additional usage directive an agent would otherwise get wrong.

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