Find a US local for a home job or errand, watch their filmed work, draft a post the person confirms
Scored across 10 tools
Most tools target clearly distinct resources (jobs vs workers vs clips vs categories). The main risk is overlap between get_worker_profile and get_work_record, and between check_service_availability and get_area_demand_density, but the descriptions explicitly differentiate the latter pair (counting locals vs measuring response) and the former (bio vs evidence).
Every tool follows a clean snake_case verb_noun pattern (browse_open_tasks, search_local_workers, get_worker_profile, list_service_categories). Verbs are used consistently (get_, list_, search_, browse_, check_) with no mixing of conventions.
10 tools is well within the ideal 3-15 range and each maps to a distinct capability (discover jobs, discover workers, view profiles/records, availability, demand, clips, categories, platform info). None appear redundant.
The surface covers discovery, drafting, profiling and platform info well for a marketplace that deliberately avoids transactions. Minor gaps: no apply-to-task tool (only a link in browse_open_tasks) and draft_job_post only drafts rather than submits, though the latter is an intentional platform constraint.
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 declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real context beyond that: coordinate privacy-offsetting, the meaning of `details` as the poster's own note, and the applicant-related fields. It stops short of any rate-limit or pagination behavior detail.
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 purpose, then return shape, then filtering — a sensible order. It is a single dense paragraph with a long field enumeration that could be trimmed, but each sentence carries usable information and nothing is filler.
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 thoroughly, enumerating title, description, details, category, budget, offset location, posting-age fields, and applicant fields. Combined with the schema's full parameter coverage and the read-only annotations, an agent has everything needed to call this 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 description coverage is 100%, so the schema already documents every parameter including the sort enum semantics and filter examples. The description largely restates the same filter and sort set, adding no syntax or format detail the schema lacks. 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 (browse) and resource (open jobs posted by homeowners on GigNGo that locals can apply to). This is clearly distinguishable from siblings like search_local_workers or get_worker_profile, which address the labor side rather than the job side.
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 clear operating context: filters are all optional and a no-argument call returns the most recent open tasks nationwide. It also nudges toward list_service_categories for category slugs, but it never states when NOT to use this tool or names a competing sibling to route to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check 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 declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds that output is a count per service and that availability is 'public locals', which is useful behavioral context beyond the annotations, though return shape details remain thin.
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 front-loaded sentences that waste little; the state-required/city-optional clause is the payload. The inline format examples ('new-jersey', 'florida') duplicate the schema and slightly bloat the text.
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 covers the return semantics ('count per service'), the input requirements, and the intended use case. An agent has everything needed to invoke and interpret this read-only 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% and both parameters are already documented with format rules and examples, so the description largely restates them ('state is required ... city is optional'). It adds the useful framing of omitting city for state-level availability, but that is also in the schema's city description.
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 ('Check which ... have public locals'), the resource (30 service categories), and the scoping dimension (US state or city), plus that a per-service count is returned. This distinguishes it from list_service_categories (no availability) and search_local_workers (worker listing, not availability).
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 clear context: 'Useful before searching, or to answer "can I get X done in Y?"'. It tells the agent when the tool applies but never names an alternative sibling or an exclusion condition (e.g., when to prefer list_service_categories or search_local_workers instead).
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.
Find 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 this is a safe, read-only, idempotent query, so the bar is lower; the description still adds real value by enumerating the returned fields (watch page URL, embed URL, first name, town, search words, profile) and disclosing the geographic ordering behavior (town -> state -> elsewhere). It omits pagination and any rate limits, keeping it short of a 5.
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 the return shape, then the ranking rule, then the caveat — a logical order with little waste. The closing "Pass on the `limits` field" sentence is ambiguous and arguably earns less than its place.
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 burden of describing returns — and it does so concretely, along with ordering semantics and an important limitation (no background checks). An agent has everything needed to call it and interpret results 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 baseline is 3; the description adds genuine meaning by explaining that city/state affect ordering and that the agent should label which ordering applies when displaying a clip. The reference to "Pass on the `limits` field" is confusing and mismatches the schema's singular `limit`, a small defect.
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 — finding short videos of locals doing a given kind of job — with concrete examples ("deck building", "pressure washing"). It clearly separates itself from siblings like search_local_workers and get_worker_profile by emphasizing verified clips of work being performed rather than 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?
Implies clear usage context: every clip is verified to show the work, and the disclaimer "a clip shows how someone works, not who they are" steers the agent toward demonstration content rather than vetting. It does not, however, name an alternative sibling or state when-not-to-use conditions.
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, 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 declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: the enumerated payload and the `limits` caveat that 'GigNGo runs no background checks,' which is a trust caveat an agent needs when summarizing a worker. It does not cover freshness, caching, or behavior for a nonexistent slug.
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 with no filler, and the purpose plus slug source are front-loaded. The long field enumeration is dense but justified because no output schema exists; only a minor trim would be possible.
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 must carry the return-value burden itself, and it does — names, bio, skills, prices, reviews, filmed-work flag, vouches, badges, service area, availability, URL, and the `limits` object. Slug acquisition and the trust caveat are both covered, leaving nothing an agent needs 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 baseline is 3; the description goes beyond the schema by explaining slug provenance (search results field or URL pattern), which is real semantic value not present in the schema's example-only description.
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 (Get), resource (public profile of one GigNGo local) and scope (by profile slug), which cleanly separates it from the list-shaped sibling search_local_workers. The scope qualifier 'one ... by their profile slug' makes it unambiguous which tool an agent should pick.
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 explicitly says where the required input comes from: 'Slugs come from search_local_workers results (the "slug" field) or from gigngo.org/worker-profile/{slug} URLs,' which routes the agent through the right prior tool. It stops short of stating when NOT to use this tool (e.g. bulk listing) or any exclusion, so it earns a 4 rather than 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.
Find a real person near someone 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?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely new behavioral context: the result ordering rule (town area-page matches with relation 'in'/'serves'/'nearby' and miles, then filmed-first), the caveat that badges are self-reported, and the per-page limit behavior. That is real disclosure beyond structured fields.
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 purpose and scope lead the description, followed by return fields and ordering rules, with formatting requirements last. It is information-dense but somewhat long; a couple of clauses (e.g. the full field list) could be tightened without losing meaning.
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 enumerates returned fields (name, bio, skills, prices, reviews, filmedTheirWork, workVideoCount, vouches, service area, profile URL) and explains ranking, so an agent can interpret results. The one gap is that no pagination mechanism beyond `limit` is described, so multi-page retrieval is ambiguous.
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 usable detail: it reiterates and exemplifies the slug/state/city formats and points to list_service_categories for slug lookup, plus clarifies that limit controls results per page. It does not explain how to page beyond the first request, which caps this at 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?
The description names a specific verb ('Find', 'Searches locals on GigNGo') and a concrete resource (real people offering home jobs/errands), with enumerated examples of the service types. It is clearly distinguishable from sibling read tools like get_worker_profile (single person) and browse_open_tasks (tasks, not people).
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 gives explicit routing guidance for the service parameter: 'Use list_service_categories first if you are unsure of the service slug.' However, it does not contrast itself with neighboring discovery tools such as get_worker_profile or find_work_clips, so the when-not-to-use case is left implicit.
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.
get_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.
Pay people nearby for physical work: find out if something is true, or have it done.
Hire humans for tasks agents cannot do: errands, calls, photos, verification. Escrowed, verified.
Add one secure layer between your agents and this server.
