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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to restate those. It adds useful behavioral detail: coordinates are privacy-offset, the 'details' field is usually the most specific part, and it lists the exact fields returned. This goes beyond annotations and helps the agent anticipate output.

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, dense paragraph that front-loads the purpose, then lists returned fields, filters, and sorting in a logical order. Every sentence contributes value; no filler. Slightly long but appropriate given the richness of the tool.

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 fully enumerates the return fields (title, description, details, category, budget, location, timestamps, applicant counts, link) and explains default behavior (no arguments returns nationwide recent tasks). It also covers all filters and sort options, making the tool fully understandable without needing additional documentation.

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 100%, so all seven parameters are documented in the input schema. The description adds semantic nuance beyond the schema, such as explaining that 'oldest' surfaces jobs about to be abandoned and 'most_applicants' shows where locals compete, which aids correct selection.

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 ('Browse') and resource ('open jobs homeowners have posted on GigNGo') and clearly differentiates from siblings like search_local_workers (workers vs. tasks) and get_platform_info. It also enumerates the data fields, filters, and sorting, leaving no doubt about what the tool does.

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?

Provides clear context on how to call the tool ('All filters are optional — call with no arguments for the most recent open tasks nationwide') and explains the meaning of sort options like 'oldest' and 'most_applicants'. It does not explicitly name alternatives or say when not to use it, but the sibling set makes the distinction obvious.

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