Find a US local for a home job or errand, watch their filmed work, draft a post the person confirms
Scored across 12 tools
Most tools have clearly distinct targets, but two pairs blur: check_job_price and check_what_to_charge return essentially the same budget statistics, differing only in the audience framing, and get_worker_profile versus get_work_record both take a slug and surface evidence about the same local. The descriptions do explicitly scope each pair (poster vs. worker, summary vs. evidence), which keeps an agent from confusing them most of the time, but the underlying overlap is real.
Every tool follows a strict snake_case verb_noun pattern (browse_open_tasks, check_job_price, get_worker_profile, list_service_categories, search_local_workers). The small family of 'check_' and 'get_' prefixes is applied consistently and each noun is unambiguous.
Twelve tools is a well-scoped set for a two-sided gig marketplace, covering discovery, pricing, profiles, and content lookup without redundancy beyond the deliberate price pair. No tool feels like filler.
The surface covers both sides of the marketplace well: browsing tasks, searching workers, pricing for poster and worker, categories, availability, demand analytics, clips, profiles, and work records. Minor gaps remain — there is no single-task detail lookup (agent must re-browse and filter) and no worker-side apply flow, though outbound links are supplied for both.
Use this when a local asks where the work is, e.g. "odd jobs near me", "yard work jobs in Dallas this week", "side jobs I can do this weekend". Browse open jobs homeowners have posted on GigNGo that locals can apply to. Each task includes title, description, details (the poster's Additional Details note, present on most jobs and usually the most specific part), category, budget, approximate location (coordinates are privacy-offset), when it was posted (postedAt, ageHours, ageDays, postedAgo), how many locals have applied (applicantCount, hasApplicants) and how fast the first one did (hoursToFirstApplicant), plus a link to apply. Filter by category, state, city, age or applicant count, and sort by newest, oldest, most_applicants or fewest_applicants. All filters are optional — call with no arguments for the most recent open tasks nationwide.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Optional city slug, lowercase with hyphens. Example: "los-angeles". | |
| sort | No | Order of results. "oldest" surfaces the jobs that have been waiting longest (the ones about to be abandoned); "most_applicants" surfaces where locals are actually competing. | |
| limit | No | Max tasks to return (1-50, default 20). | |
| state | No | Optional full US state name, lowercase, hyphens for spaces. Example: "pennsylvania". | |
| category | No | Optional service category slug, e.g. "moving-help". See list_service_categories. | |
| maxAgeDays | No | Only tasks posted within this many days. | |
| unanswered | No | Only tasks with zero applicants so far — the unfilled queue. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, non-open-world behavior, but the description adds substantial context: result fields, privacy-offset coordinates, applicant counts, age indicators, and default nationwide behavior. This gives an agent useful operational detail beyond the annotations without contradicting them.
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 front-loaded with the primary use case, then efficiently covers results, filtering, sorting, and default behavior. Despite being a dense paragraph, every sentence contributes relevant information for invoking the tool correctly.
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 appropriately explains the returned fields and link to apply. Combined with complete schema descriptions and annotations covering safety behavior, an agent has enough information to select and invoke this tool correctly.
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 the schema already carries most parameter semantics. The description adds helpful default behavior ('call with no arguments for the most recent open tasks nationwide') and summarizes filter/sort capabilities, though most parameter-level detail remains in 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 description gives a specific verb and resource: browse open jobs posted by homeowners that locals can apply to. The examples ('odd jobs near me', 'yard work jobs in Dallas this week') make the intended resource and audience unambiguous, distinguishing it from sibling tools focused on pricing, worker search, or platform info.
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?
It clearly states when to use the tool via concrete local-user phrasing and explains that filters are optional with a no-argument nationwide default. It does not explicitly name alternatives or when not to use it, so it falls short of a full when/when-not/alternatives rubric.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks what a home job or errand costs or what to pay for it, e.g. "how much to mow a lawn", "what do movers charge", "what should I pay for TV mounting". Returns the middle budget and the middle half of budgets that people set when they posted that job on GigNGo, with how many posts it counts and a link to the cost guide. These are budgets from across the US, not quotes, not local prices and not prices paid for finished jobs: say so, with the number of posts. A job with fewer than 5 posts has no figure; the reply then lists the jobs that do. Pass on the limits field.
| Name | Required | Description | Default |
|---|---|---|---|
| job | Yes | The job in a few words, e.g. "lawn mowing", "moving help", "tv mounting". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare it a safe read, and the description adds substantial context beyond them: the data is US-wide posted budgets, explicitly not quotes, not local prices and not prices paid, must be reported with the post count, has a 5-post minimum, and the `limits` field must be relayed. That is exactly the kind of caveat an agent would otherwise get wrong.
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 trigger condition is front-loaded, followed by what is returned, the mandatory caveat, the empty-result behavior and the `limits` handoff. Each sentence carries a distinct instruction; nothing repeats the schema or the title.
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 carries the return-value burden and does: median, interquartile range, post count and cost-guide link. Edge-case behavior and the required user-facing disclaimer are both covered, so an agent can both call and report correctly.
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% and the single `job` param is already documented, so the baseline is 3. The description pushes slightly above it by showing the natural-language granularity callers use ("how much to mow a lawn", "what do movers charge"), which signals a short phrase rather than a category ID.
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 and resource — returns the middle budget and the middle half of budgets people set for a posted job — with three concrete example queries. No sibling tool covers pricing, and the description makes that domain obvious without opening a schema.
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?
"Use this when someone asks what a home job or errand costs or what to pay for it" gives an explicit trigger, reinforced by three sample phrasings. It also states when the tool cannot answer (fewer than 5 posts) and what to do instead, which is the closest thing to an alternative-path rule here.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this for "can I get my gutters cleaned in Orlando?" or "is there anyone in my town who does this?". Checks which of the 30 service categories have public locals in a US state or city, with a count per service. Useful before searching, or to answer "can I get X done in Y?". State is required (full name, lowercase, hyphens: "new-jersey"); city is optional — omit it for state-level availability.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Optional city name, lowercase, hyphens for spaces. Example: "orlando". Omit for state-wide availability. | |
| state | Yes | Full US state name, lowercase, hyphens for spaces. Example: "florida". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, closed-world semantics, so the bar is lower. The description adds genuinely new behavior context: the scope (30 service categories, US only), the per-service count in the response, and the availability prerequisite of "public locals" — none of which are in the annotations or schema.
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 lead is front-loaded with the decision-relevant phrasing and the alternative framing, then the operational details. Slight redundancy between the quoted example questions and the later "can I get X done in Y?" restatement costs it a point.
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 usefully discloses that the return is a per-service count, and it defines required vs optional inputs and their format. An agent has enough to call it and interpret the result; only the exact result shape (category list structure) is left implicit.
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% and both params already document lowercase hyphenated formatting with examples. The description restates the same format rules ("full name, lowercase, hyphens: 'new-jersey'") and the omit-city-for-state-level rule, so it adds little beyond the schema — the baseline 3 is appropriate.
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 and resource: checks which of the 30 service categories have public locals in a given state or city, returning a count per service. This is clearly distinguishable from search_local_workers (which finds individuals) and list_service_categories (which enumerates categories), so an agent can route correctly without opening schemas.
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 concrete user-question framings ("can I get my gutters cleaned in Orlando?") and positions itself as "useful before searching," which implies the ordering relative to search_local_workers. It does not name the sibling explicitly or state when NOT to use it, keeping it short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone who does the work asks what to charge, e.g. "what should I charge to mow a lawn", "how much do people pay for TV mounting", "what can I make doing yard cleanup". Returns the middle budget and the middle half of budgets homeowners set when they posted that job on GigNGo, with how many posts it counts and a link to the earnings guide. These are budgets from across the US, not prices paid for finished jobs and not what any local earned: say so, with the number of posts. A job with fewer than 5 posts has no figure; the reply then lists the jobs that do. Pass on the limits field.
| Name | Required | Description | Default |
|---|---|---|---|
| job | Yes | The job in a few words, e.g. "lawn mowing", "furniture assembly", "tv mounting". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare this is a safe, idempotent read; the description adds substantive behavior the annotations can't convey: the statistical shape of the return (median plus middle half), post-count disclosure, a coverage caveat the agent must relay verbatim, a hard minimum of 5 posts with fallback behavior (lists jobs that do have figures), and an instruction to pass on the `limits` field.
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 triggering use case, then what is returned, then the caveats and the sub-5-post fallback. No sentence is filler: even the caveat about US-wide budgets and the `limits` passthrough change how the agent should phrase its answer.
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?
There is no output schema, and the description compensates fully by describing the return contents, the count disclosure, the link, the insufficient-data path, and the required caveat language. An agent can both call this correctly and relay its output accurately from the description alone.
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% and the single `job` parameter is already documented with examples such as 'lawn mowing' and 'tv mounting'. The description's examples are query phrasings rather than additional parameter constraints, so it adds little semantics beyond the schema; baseline 3 applies.
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 states a specific user scenario (someone who does the work asking what to charge) and precisely what comes back: the middle budget, the middle half of budgets, post count, and a link. It also draws a sharp semantic boundary against other price data ('not prices paid for finished jobs, not what any local earned'), though it never names the sibling check_job_price, so routing between the two still requires an inference.
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 opening 'Use this when someone who does the work asks what to charge' gives a clear triggering condition, reinforced by three realistic example utterances. It stops short of naming a when-not case or an explicit alternative tool (e.g. check_job_price for homeowner-side or paid-price questions), which would be needed for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone needs a local to do a job or errand for them (put furniture together, mow a lawn, help move, pick something up, wait in line) and wants it posted. Draft the job post and get back a link THEY open to review and post it. Posting is free. You cannot hire, book or pay anyone through this tool: the person posts the job, locals nearby decide whether to offer, and the person chooses who to hire. GigNGo never posts on anyone's behalf: this writes nothing. The draft is run through the same screens a real post faces, so if it reads as vague, as an advert, as a job advert or as a known scam pattern you get the reason back and can fix it before handing the person a link. Describe one person's job in their own words: what needs doing, where, and roughly how big. GigNGo runs no background checks; say so when you hand over the link.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Optional city, e.g. "Saginaw". | |
| state | No | Optional US state, e.g. "michigan" or "MI". | |
| title | No | Optional short title, e.g. "Fence repair". | |
| category | No | Optional service slug or id. See list_service_categories. | |
| description | Yes | The job in the homeowner's words, 12-1000 characters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Rich disclosure beyond annotations: free posting, no background checks, draft passes the same screens as a real post with failure reasons returned, and a clear hand-off responsibility (say no background checks when handing over the link). One phrase, 'this writes nothing', sits awkwardly against readOnlyHint=false since a draft is persisted and a link is minted; it reads as 'does not post publicly' but is loose enough to be mildly misleading.
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-loads the trigger scenario and the returned artifact before the constraints. Slightly long, with mild redundancy between 'GigNGo never posts on anyone's behalf', 'this writes nothing', and the posting/choosing flow, but nearly every sentence adds a constraint the agent could not infer.
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?
For a 5-param draft tool with no output schema, it covers the return value (a link), the screening behavior and error reasons, the platform's non-participation, and what the agent must tell the end user. Nothing needed to call it correctly 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?
Schema coverage is 100%, so the baseline is 3, but the description adds real content guidance for the required field: one person's own words, what needs doing, where, and roughly how big, plus the screening criteria the text will be judged against.
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 (draft a job post) and the exact artifact returned: a link the person opens to review and post. It also names what it is not — no hiring, booking, paying, or posting — which lets an agent separate it from every sibling that searches or browses.
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 an explicit triggering scenario with concrete examples (put furniture together, mow a lawn, help move, wait in line) and explicit exclusions ('You cannot hire, book or pay anyone through this tool'). No sibling is mis-selected after reading this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone wants to see the work before they hire, e.g. "show me someone pressure washing a driveway", "videos of deck staining near Grand Rapids". Finds short videos of locals doing a kind of job, e.g. "deck building", "pressure washing", "house cleaning". Every clip was checked to show someone actually doing the work. Returns a watch page URL (link people there), an embed URL, the local's first name and town, the job's search words, and the local's profile. With a city or state, clips from that town come first (where: "town"), then that state ("state"), then anywhere ("elsewhere") — say which when you show one. A clip shows how someone works, not who they are: GigNGo runs no background checks. Pass on the limits field.
| Name | Required | Description | Default |
|---|---|---|---|
| job | Yes | The job in a few words, e.g. "deck staining", "furnace repair". | |
| city | No | Optional city, lowercase, hyphens for spaces. Example: "grand-rapids". | |
| limit | No | Max clips (1-20, default 8). | |
| state | No | Optional US state, full name ("michigan") or code ("MI"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the description correctly spends its space on richer traits: the verification that every clip shows someone actually working, the geo priority ordering (town, then state, then elsewhere), and the no-background-checks caveat. The closing instruction 'Pass on the `limits` field' is puzzling since the schema has `limit` (singular) and no output schema exists to confirm a `limits` return field.
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 trigger condition and examples, then returns, then ordering, then caveat, in priority order. Dense but every sentence carries information an agent would otherwise have to guess.
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 carries the return-value burden and does so well (watch page URL, embed URL, first name, town, job search words, profile). Only the ambiguous 'limits' field instruction leaves a loose end for the calling agent.
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 the schema itself documents job/city/state/limit. The description still adds value by explaining what city and state actually do to result ordering and by telling the agent to state the 'where' bucket when presenting a clip — semantics the schema does not carry.
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 and resource ('Finds short videos of locals doing a kind of job') with three concrete job examples. The agent can distinguish this from search_local_workers because the deliverable is clips of work being performed, not worker listings.
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 trigger phrasings ('show me someone pressure washing a driveway', 'videos of deck staining near Grand Rapids') and the hiring context that selects it. It never names a sibling tool or a when-not condition, so routing versus search_local_workers is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find which US cities are actually converting: how many jobs each area posted, how many locals applied, what share of jobs got any reply at all, and the median hours to the first applicant. Ranked by a "heat" score that combines applicant density with response reliability, shrunk toward the platform average so a single lucky job cannot outrank a real market — read heat next to confidence. Use this to decide where supply is dense (spend more) versus where jobs go unanswered (a supply hole). Complements check_service_availability, which counts locals rather than measuring whether they respond.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Ranking. "openUnanswered" surfaces supply holes instead of hot markets. | |
| limit | No | Max areas to return (1-300, default 50). | |
| state | No | Optional state filter — full name or two-letter code, e.g. "texas" or "TX". | |
| minJobs | No | Only areas with at least this many jobs in the window. Use 5+ for a shortlist of established markets; smaller areas are real but weigh less as evidence. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds real behavioral context: the heat score is shrunk toward the platform average to prevent one lucky job from ranking high, and it instructs reading heat alongside confidence. It stops short of describing pagination or window semantics, but that is minor given the annotation coverage.
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?
Purpose is front-loaded in the first clause and each subsequent clause adds a distinct measure or caveat rather than restating. The single long sentence is dense and readable, though slightly packed relative to the minimal information an agent strictly needs.
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 carries the full burden of explaining returns and does so: jobs, applicants, reply share, median first-response hours, heat, and confidence. Combined with 100% schema coverage on the four filters, an agent has everything needed to call and interpret this tool.
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 baseline is 3, but the description adds interpretive meaning beyond the schema — how heat/confidence relate and why the shrinkage matters — which informs the sort and confidence parameters. It does not add syntax or format detail beyond the schema, so it stays below a 5.
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?
Opens with a specific verb and resource ('Find which US cities are actually converting') and enumerates the concrete measures returned (jobs posted, locals applied, reply share, median hours to first applicant). It explicitly names and differentiates itself from the sibling check_service_availability, so an agent can choose between them without opening schemas.
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?
States the decision this tool informs ('decide where supply is dense (spend more) versus where jobs go unanswered (a supply hole)') and names the alternative tool plus the axis on which they differ (counting locals vs measuring whether they respond). Both when-to-use and the sibling comparison are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get an overview of GigNGo: what it is, what it does not do (limits), service category count, how jobs reach locals, iOS/Android app links, and API documentation URLs. Call this for general "what is GigNGo" questions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely useful behavioral context by disclosing that the payload includes documented limitations ('what it does not do') and static links, letting the agent anticipate what it will and won't learn from the call.
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?
Two sentences, zero filler: the content enumeration is front-loaded and the usage cue follows immediately. Every clause carries information an agent needs.
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?
For a no-parameter, no-output-schema read tool, the description fully specifies what the response covers, so an agent knows the scope of the result without a return schema.
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?
The tool takes zero parameters, so the baseline of 4 applies; there is nothing parameter-wise for the description to clarify or compensate for.
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 an overview of GigNGo') and enumerates exactly what the overview contains (limits, category count, job-dispatch explanation, app links, API URLs). This is clearly distinguishable from every sibling, which are all task- or lookup-oriented rather than informational.
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?
Explicitly routes the agent with 'Call this for general "what is GigNGo" questions,' which gives a clear triggering condition. It stops short of naming alternatives or when-not-to-use cases, so it is strong but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the public profile of one GigNGo local by their profile slug. Returns name, bio, skills, prices the local set, reviews, whether they filmed their work, neighbor vouches (with what named neighbors said), the lines the local picked for "you'll probably like working with me if", self-reported badges, service area, availability, a profile URL and limits (GigNGo runs no background checks). Slugs come from search_local_workers results (the "slug" field) or from gigngo.org/worker-profile/{slug} URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The local's profile slug, e.g. "john-smith-handyman-orlando". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, closed-world behavior, so the description's job is supplemental — and it delivers meaningfully by flagging that returned data includes `limits` because GigNGo runs no background checks and badges are self-reported. That trust caveat is real behavioral context an agent would otherwise miss; it omits any note about missing/deleted profiles or rate limits.
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?
Purpose is front-loaded in the first clause, and the second sentence's field inventory substitutes for the absent output schema, so most of its length is earned. The enumeration is dense and could be grouped more tightly, but no sentence is redundant.
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?
For a single-parameter read tool with no output schema, the description supplies everything needed: what is fetched, how to obtain the key, what comes back, and the safety caveat on that data. Nothing required to call or interpret it correctly 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?
With 100% schema coverage the baseline is 3, and the description adds value beyond the schema's format example by naming concrete sources for the slug value. It does not discuss slug validity, case sensitivity, or fallback behavior, so it modestly exceeds the schema rather than fully enriching it.
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 and resource ("Get the public profile of one GigNGo local by their profile slug") plus the exact lookup key and scope. It is clearly distinct from sibling search_local_workers, which finds slugs rather than resolving one.
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 tells the agent where valid slugs come from — search_local_workers results or gigngo.org/worker-profile/{slug} URLs — which implicitly establishes the lookup-then-fetch workflow with its sibling. It does not state explicit when-not conditions or error behavior for unknown slugs, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a local's Work Record: evidence of their work, where every item says how GigNGo knows it. Evidence types: filmed (clips our check says show the work, not who is in them), homeowner_confirmed / local_reported / inferred_from_messages (finished jobs, counted), neighbor_vouched, recorded_on_gigngo (reviews, member since) and self_reported (badges). Weigh each evidence type separately; never reduce the record to one score. GigNGo runs no background checks. Not for employment, credit, insurance or tenancy decisions. Use the "slug" from search_local_workers or get_worker_profile as the handle.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes | The local's public handle or profile slug, e.g. "juan-lopez-handyman". |
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.
List all 30 GigNGo service categories with their slugs (e.g. "house-cleaning", "electrician", "moving-help"). Call this to discover valid values for the service parameter of search_local_workers and the category parameter of browse_open_tasks.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered and the description correctly does not contradict it. The description adds genuine value by disclosing the cardinality (30 categories) and that slugs are returned, which shapes the agent's expectations. It stops short of describing return ordering or whether new categories can appear, so it is not exhaustive.
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?
Two sentences, no boilerplate. The what (list categories with slugs) comes first, and the why/when (discovering valid `service` and `category` values) follows, so the agent gets orientation before routing detail.
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?
For a zero-parameter, read-only enumeration tool, the description supplies everything needed: the resource, its size, example output shape, and the cross-tool purpose. With annotations covering the safety profile and no output schema to explain, no material gap remains.
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?
The tool takes zero parameters, so the schema cannot carry meaning and the baseline is 4. The description appropriately spends no space on parameter syntax and instead clarifies the downstream parameters this output satisfies, which is the only relevant semantic information here.
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 and resource ('List all 30 GigNGo service categories with their slugs') and immediately grounds it with concrete examples like 'house-cleaning' and 'electrician'. It also distinguishes itself from siblings by naming the two tools whose enum-like parameters it feeds.
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?
Explicitly states when to call it: to discover valid values for the `service` parameter of search_local_workers and the `category` parameter of browse_open_tasks. This is a precise when-to-use instruction with named alternatives, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone wants a person nearby to do a job, e.g. "someone to mow my lawn in Dallas", "a handyman near me", "help moving a couch", "who can clean my house in Orlando". Finds a real person near them in the US who does a kind of home job or errand: assembly, yard work, cleaning, moving help, hauling, small repairs, pickups. Searches locals on GigNGo by service and place. Returns public profiles: name, bio, skills, prices the local set, reviews, whether they filmed their work (filmedTheirWork, workVideoCount), neighbor vouches, service area and profile URL. With a city, locals listed on that town's GigNGo area page come first (relation "in", "serves" or "nearby", with miles), then locals in that town, ordered so those who filmed their work come first. Badges are self-reported. Use list_service_categories first if you are unsure of the service slug. State is the full state name in lowercase with hyphens (e.g. "new-york", "north-carolina"); city likewise (e.g. "los-angeles"). Returns up to limit locals per page.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Optional city name, lowercase, hyphens for spaces. Example: "san-francisco". | |
| limit | No | Max locals to return (1-50, default 20). | |
| state | Yes | Full US state name, lowercase, hyphens for spaces. Example: "new-york". | |
| service | Yes | Service category slug, e.g. "house-cleaning", "handyman", "lawn-care". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent/non-destructive annotations by disclosing result ordering semantics (town area-page locals first with relation 'in'/'serves'/'nearby' plus miles, then in-town locals, filmed-work profiles boosted), the pagination contract ('up to `limit` locals per page'), and that badges are self-reported. That ordering logic is behavior an agent could not infer from any structured field.
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 use case and examples before any mechanics, and most sentences carry new information (ordering, return fields, slug fallback). The state/city hyphenation rules are repeated from the schema descriptions, which is the main redundancy.
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?
There is no output schema, so the description carries the return contract itself and does so fully: name, bio, skills, prices, reviews, filmedTheirWork/workVideoCount, vouches, service area, profile URL. Combined with the ordering and pagination notes, an agent has everything needed to call it and interpret results.
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 the baseline is 3; the description earns an extra point by explaining what `city` actually changes (area-page locals ranked first with a relation and mileage) and by reinforcing the slug/state formatting contract. It restates some schema formatting guidance, which limits it to a 4.
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 and resource: finds real local people on GigNGo by service and place for home jobs and errands, with concrete category examples (assembly, yard work, cleaning, moving, hauling, repairs, pickups). This is clearly distinguishable from siblings like get_worker_profile (single known person) and list_service_categories (slug lookup).
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?
Opens with an explicit trigger ('Use this when someone wants a person nearby to do a job') backed by four natural-language query examples, and routes the agent to list_service_categories when the service slug is unknown. The only minor gap is the absence of an explicit 'do not use this for X' exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_what_to_chargecheck_job_priceget_area_demand_density1 field changedInput schema / properties / minJobs / descriptionPrevious value: -"Only areas with at least this many jobs in the window. Use 5+ for a fundable shortlist; thin areas are informative but not yet evidence."New value: +"Only areas with at least this many jobs in the window. Use 5+ for a shortlist of established markets; smaller areas are real but weigh less as evidence."find_work_clipsdraft_job_postget_work_recordget_worker_profile1 field changedInput schema / properties / slug / descriptionPrevious value: -"The worker's profile slug, e.g. \"john-smith-handyman-orlando\"."New value: +"The local's profile slug, e.g. \"john-smith-handyman-orlando\"."search_local_workers1 field changedInput schema / properties / limit / descriptionPrevious value: -"Max workers to return (1-50, default 20)."New value: +"Max locals to return (1-50, default 20)."browse_open_taskscheck_service_availabilityget_area_demand_densityget_platform_infoget_worker_profilelist_service_categoriessearch_local_workersHire vetted local people for real-world jobs: post, rank, hire, pay in escrow, verify with photos.
Hire a real human for real-world verification, product testing, AI output review, and errands.
Hire verified local people for real-world tasks. Paid upfront, released on approved photo proof.
Pay people nearby for physical work: find out if something is true, or have it done.
Add one secure layer between your agents and this server.
