Mundane

search_workers

Read-onlyIdempotent

Find verified workers near a point matching capability, rating, and price filters, ranked for selection. ask_rate_minor is each worker's enforced minimum per-task price in minor units; ask_rate_basis is per_task, and max_rate_minor filters on that same basis. rate_card contains advisory per-task asks for labeled work. When the task fits a label, offer at least that entry's rate_minor; labels are informational and are not matched or enforced by the offer endpoint. Does not commit funds.

distance_km is to the centre of the worker's ~2 km grid cell, not to the worker, and the radius is applied the same way: close enough to plan a trip, never enough to locate anyone.

For tasks needing immediate execution, set live_now=true; otherwise leave it off. Every result includes live_now and live_until. Presence is explicit and self-expiring, and live workers receive a ranking lift in ordinary searches.

skill filters on workers' free-form self-declared qualifiers (e.g. 'welding', 'bio lab support', 'notary') — an open vocabulary, fuzzy-matched (case-insensitive, tolerant of typos and word order, and matching a query word inside a multi-word tag). When the marketplace has semantic matching enabled, natural-language queries also bridge synonyms ('move heavy boxes' finds 'lifting heavy items') and a strong semantic match lifts match_score; if results look sparse, still try the worker's own likely wording or search without skill and read each result's skills list.

Input Schema

TableJSON Schema

Name	Required	Description
`lat`	Yes	Latitude of the centre of the search, decimal degrees.
`lng`	Yes	Longitude of the centre of the search, decimal degrees.
`limit`	No	Maximum number of workers to return.
`skill`	No	Optional free-text skill matched against workers' own skill labels.
`live_now`	No	Only workers currently marked as available.
`radius_km`	No	How far from that centre to look, in kilometres.
`capability`	No	Optional capability the worker must hold. Use an exact slug from list_capabilities.
`min_rating`	No	Only workers at or above this rating, 0 to 5. Leave at 0 to include unrated workers.
`max_rate_minor`	No	Only workers whose asking rate is at or below this, integer minor units.
`min_rating_count`	No	Only workers with at least this many ratings. Leave at 0 to include new workers.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedSep 22, 2026

addedInput schema / properties / capability / description

Added value: +"Optional capability the worker must hold. Use an exact slug from list_capabilities."

addedInput schema / properties / lat / description

Added value: +"Latitude of the centre of the search, decimal degrees."

addedInput schema / properties / limit / description

Added value: +"Maximum number of workers to return."

addedInput schema / properties / live_now / description

Added value: +"Only workers currently marked as available."

addedInput schema / properties / lng / description

Added value: +"Longitude of the centre of the search, decimal degrees."

addedInput schema / properties / max_rate_minor / description

Added value: +"Only workers whose asking rate is at or below this, integer minor units."

addedInput schema / properties / min_rating / description

Added value: +"Only workers at or above this rating, 0 to 5. Leave at 0 to include unrated workers."

addedInput schema / properties / min_rating_count / description

Added value: +"Only workers with at least this many ratings. Leave at 0 to include new workers."

addedInput schema / properties / radius_km / description

Added value: +"How far from that centre to look, in kilometres."

addedInput schema / properties / skill / description

Added value: +"Optional free-text skill matched against workers' own skill labels."

First observedSep 22, 2026

TDQS

A4.5/5.0

Behavior5/5

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 material context beyond them: no funds are committed, distance_km is measured to the ~2 km grid cell centre rather than the worker for privacy, live presence is explicit and self-expiring with a ranking lift, and rate_card is advisory only. This is exactly the kind of behavior annotations cannot express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded and the paragraphs are organized by concern (pricing, distance/privacy, live_now, skill). It is on the long side with some restatement of field names, but nearly every sentence carries information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 10 parameters, an output schema, and rich annotations, the description covers the decisive nuance: pricing basis, privacy-preserving distance, live availability, and skill-matching fallbacks. It also previews key result fields (live_now, live_until, match_score, skills) which the output schema documents, so nothing an agent needs 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.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description still adds meaning the schema lacks: ask_rate_minor is an enforced minimum per-task price in minor units, max_rate_minor filters on that same per_task basis, rate_card is advisory, and skill is fuzzy case-insensitive open-vocabulary matching with optional semantic synonym bridging that lifts match_score. These go well beyond the schema's one-line field descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a specific verb, resource and scope: 'Find verified workers near a point matching capability, rating, and price filters, ranked for selection.' It also clarifies the tool is non-committal ('Does not commit funds'). It does not explicitly distinguish itself from the sibling find_workers_by_skill, leaving that routing to inference, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives actionable conditions: set live_now=true only for immediate-execution tasks, leave it off otherwise; try the worker's own wording or drop skill when results look sparse. However it never names find_workers_by_skill as the alternative for pure skill lookup, so the when-not/alternative guidance is incomplete.

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

All Mundane tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.