Worklittle Jobs

search_jobs

Read-onlyIdempotent

Jobs — Opens the Worklittle jobs MAP for a place and an optional role. This is a map query, not a list of jobs: the map recenters on the place and shows jobs there, so send the place and the role as SEPARATE fields. Never write 'product manager in San Francisco' as one query. PLACE: always pass near_lat + near_lng (the city's coordinates, which you know) and location as the display name (e.g. 'San Francisco, CA'). radius_km 25-50 for a city. If the user names no place, omit all place fields; the map opens at the user's approximate (IP-based) area. When a nearby search runs short, results widen to the rest of the country and then worldwide (search.scope says which: near, country or world), so say where the roles are. ROLE: query holds only the job title text (e.g. 'product manager') and may be omitted for 'any job'. Search Worklittle job listings. People say Worklittle plus a role, city, company, or filters (or just 'jobs') — they will not name this tool. Call it whenever they want Worklittle jobs. Search by keyword, company, location, job type, seniority, or recency. Use for ANY industry (retail, finance, healthcare, tech, etc.). Search matches title and filter text (substring / FTS), not vector embeddings. Role / title text goes in query (+ optional keywords). The API matches job TITLE substrings only for that text — it does not mix company names into the same field. Preserve negative title terms with a leading dash, e.g. 'software engineer, -senior' excludes titles containing senior. Use company for employer slugs (include or exclude). Never concatenate many job titles into one query unless the user supplied comma-separated roles. Do not add seniority_level, stacks, or resume-derived terms unless they asked. Omit seniority_level unless they explicitly name a level as an inclusion filter (never infer from profile). Expand abbreviations only; umbrella phrases use neutral roles and/or company slugs. Umbrella or vague phrases ('big tech', 'FAANG', 'top retailers'): interpret intent, then one search_jobs with comma-separated company slugs and/or a broad role query — prefer one API call over many. company MUST be employer slug(s): bare slugs include (OR), e.g. meta,google,apple. Prefix a slug with '-' to exclude, e.g. -lucid-motors,-tesla. Same leading-dash rule as title negatives, but in company not query. Expand 'no car companies' / 'don't show Lucid' into -slug tokens. Never pass display names as query. If unsure of slug, try lowercase hyphenated brand. Add skills or stack to query/keywords only when the user mentioned them — not from profile by default. When an include company filter returns 0 results, try a broader query (drop include company, use role keywords) before telling the user nothing matched. Pass cursor from a previous response to paginate. Search is anonymous. Do not call get_account, apply, or ask the user to Connect to search or skip. Connect / OAuth is only when they apply. After the map renders, briefly say what was found and where (listed pay shows on each job). For visa / H-1B: set visa_sponsorship to 'yes' (plus optional query). Postings must be explicitly tagged. When visa_sponsorship is set and posted_within_days is omitted, do not apply the default 7-day recency cutoff — tagged visa roles are sparse. For regional / nearby intent: near_lat, near_lng, radius_km (e.g. 50–65). Prefer this over the location substring when coordinates are known. For two or more metros in one user message (e.g. SF or NYC), pass location_or as comma-separated place names — one API request matches ANY listed place. Do not use near_* for multi-metro; use location_or or location with 'or' between cities. Recency: set posted_within_days from the user's words — today/just posted → 1; past few days → 3; this week → 7; past two weeks → 14; this month → 30. Omit when they did not mention timing (defaults to the last 7 days, the map's default). Set 0 only when they want any age / no date limit. Never put today/new/this week into query. Filters are the same as the map's filter chips, and nothing else: posted_within_days (Past 24 hours / 3 / 7 / 14 / 30 days), seniority_level (Experience: intern, entry/new grad, senior, manager, director/executive), employment_type (Type: full-time, part-time, contract), and visa_sponsorship (Visa). Prefer no filters: use one only when the user explicitly asks for it, because each filter shrinks the results a lot. For remote-only jobs send remote: true (and no place fields). There is no salary, hybrid, or benefits filter. If the user asks to filter by salary, search without it and say they can see salaries on the map (listed pay shows on each job).

Input Schema

Name	Required	Description
`limit`	No	Number of results to return. Default 10, max 50.
`query`	No	Job title or role phrase (merged with keywords). Sent as API title= — matches job TITLE text only, separate from company. Preserve negative title terms with a leading dash, e.g. 'product manager, software engineer, -senior'. If they want any role / all jobs, omit. Never merge many titles into one string unless the user supplied comma-separated roles. Expand shorthand (swe, pm, sre) when applicable.
`cursor`	No	Pagination cursor from a previous search_jobs response to fetch the next page.
`remote`	No	true: remote jobs only (any country unless country is set). Leave out place fields. location 'remote' does the same.
`company`	No	Employer slug(s): bare slug or comma-separated OR include (e.g. meta,google,apple). Prefix with '-' to exclude (e.g. -lucid-motors,-tesla). Mix allowed (meta,google,-amazon). Lowercase hyphenated. Mid-slug hyphens are part of the slug; only a leading '-' excludes. If include-only returns 0, retry without include slugs.
`country`	No	ISO 3166-1 alpha-2 country filter (e.g. US, GB, DE). Returns jobs in that country or workplace_type remote.
`keywords`	No	Only if the user named skills or stacks in this turn. Omit by default — do not pull from resume or profile.
`location`	No	Display name of the place (e.g. 'San Francisco, CA'). When near_lat/near_lng are set this is only a label and is NOT used as a text filter. Otherwise a text filter on job location strings (partial match). For metro-area or 'near me' intent, prefer near_lat + near_lng + radius_km (50–65 km typical) so results are not tied to one city spelling. Use location only when you cannot geocode, or as a fallback. Avoid long 'City, Country' strings; use country for country filters. For multiple metros, prefer location_or.
`near_lat`	No	Latitude for distance search. Use with near_lng. Typical source: browser geolocation or geocoded city.
`near_lng`	No	Longitude for distance search. Required with near_lat.
`radius_km`	No	Radius in kilometers around near_lat/near_lng. Default 50, max 500.
`exclude_ids`	No	Comma-separated job IDs to exclude (e.g. postings already shown in the conversation).
`location_or`	No	Comma-separated place substrings when the user names two or more metros at once (e.g. San Francisco,New York). The API returns jobs whose location text matches ANY term. Mutually exclusive with distance search (near_lat/near_lng).
`exclude_remote`	No	When using near_lat/near_lng: false includes remote-only jobs; true (default) excludes them so results are geographically local.
`employment_type`	No	Type of employment contract.
`seniority_level`	No	Omit unless the user explicitly asked for a band. Never infer from profile. Enum when set:
`visa_sponsorship`	No	Filter by explicit visa sponsorship text in the posting (AI-extracted). Use 'yes' for jobs that sponsor visas (H-1B, etc.). Use 'no' only when the user wants roles that explicitly state no sponsorship. Omit when not relevant.
`posted_within_days`	No	Days of posted-date lookback. Omit → default 7 (map default). 0 → no cutoff (any age). 1 → today/last 24h. 7 → this week. Any positive integer allowed (e.g. 90, 365). Never encode recency words in query.
`description_language`	No	ISO 639-1 code for the language of the job posting body. Examples: en, es, de, fr, pt.

Output Schema

Name	Required	Description
`jobs`	No	Matching job listings.
`query`	No
`total`	No	Total matches when provided by the API.
`cursor`	No	Pagination cursor for the next page.
`search`	No	Echo of search_jobs filters for the Job Cards widget.
`location`	No
`near_lat`	No
`near_lng`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 28, 2026

addedInput schema / properties / remote

Added value: +{
+  "description": "true: remote jobs only (any country unless country is set). Leave out place fields. location 'remote' does the same.",
+  "type": "boolean"
+}

Changed3 schema fields changedOct 3, 2026

changedInput schema / properties / posted_within_days / description

Previous value: -"Days of posted-date lookback. Omit → default 14. 0 → no cutoff (any age). 1 → today/last 24h. 7 → this week. Any positive integer allowed (e.g. 90, 365). Never encode recency words in query."New value: +"Days of posted-date lookback. Omit → default 7 (map default). 0 → no cutoff (any age). 1 → today/last 24h. 7 → this week. Any positive integer allowed (e.g. 90, 365). Never encode recency words in query."

removedInput schema / properties / salary_min

Removed value: -{
-  "description": "Minimum annual salary in the job's listed currency. Only returns jobs where a salary is known and meets this threshold. Examples: 100000, 150000.",
-  "minimum": 0,
-  "type": "number"
-}

removedInput schema / properties / workplace_type

Removed value: -{
-  "description": "Work arrangement.",
-  "enum": [
-    "remote",
-    "hybrid",
-    "on_site"
-  ],
-  "type": "string"
-}

Changed1 schema field changedOct 3, 2026

changedInput schema / properties / location / description

Previous value: -"Text filter on job location strings (partial match). For metro-area or 'near me' intent, prefer near_lat + near_lng + radius_km (50–65 km typical) so results are not tied to one city spelling. Use location only when you cannot geocode, or as a fallback. Avoid long 'City, Country' strings; use country for country filters. For multiple metros, prefer location_or."New value: +"Display name of the place (e.g. 'San Francisco, CA'). When near_lat/near_lng are set this is only a label and is NOT used as a text filter. Otherwise a text filter on job location strings (partial match). For metro-area or 'near me' intent, prefer near_lat + near_lng + radius_km (50–65 km typical) so results are not tied to one city spelling. Use location only when you cannot geocode, or as a fallback. Avoid long 'City, Country' strings; use country for country filters. For multiple metros, prefer location_or."

Changed1 schema field changedOct 3, 2026

changedInput schema / properties / location / description

Previous value: -"Display name of the place (e.g. 'San Francisco, CA'). When near_lat/near_lng are set this is only a label and is NOT used as a text filter. Otherwise a text filter on job location strings (partial match). For metro-area or 'near me' intent, prefer near_lat + near_lng + radius_km (50–65 km typical) so results are not tied to one city spelling. Use location only when you cannot geocode, or as a fallback. Avoid long 'City, Country' strings; use country for country filters. For multiple metros, prefer location_or."New value: +"Text filter on job location strings (partial match). For metro-area or 'near me' intent, prefer near_lat + near_lng + radius_km (50–65 km typical) so results are not tied to one city spelling. Use location only when you cannot geocode, or as a fallback. Avoid long 'City, Country' strings; use country for country filters. For multiple metros, prefer location_or."

Changed1 schema field changedOct 2, 2026

changedInput schema / properties / location / description

Previous value: -"Text filter on job location strings (partial match). For metro-area or 'near me' intent, prefer near_lat + near_lng + radius_km (50–65 km typical) so results are not tied to one city spelling. Use location only when you cannot geocode, or as a fallback. Avoid long 'City, Country' strings; use country for country filters. For multiple metros, prefer location_or."New value: +"Display name of the place (e.g. 'San Francisco, CA'). When near_lat/near_lng are set this is only a label and is NOT used as a text filter. Otherwise a text filter on job location strings (partial match). For metro-area or 'near me' intent, prefer near_lat + near_lng + radius_km (50–65 km typical) so results are not tied to one city spelling. Use location only when you cannot geocode, or as a fallback. Avoid long 'City, Country' strings; use country for country filters. For multiple metros, prefer location_or."

First observedSep 1, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Adds real context beyond annotations: 'Search is anonymous. Do not call get_account, apply, or ask the user to Connect,' OAuth only on apply, and the near→country→world widening with search.scope semantics. These are non-obvious behavioral traits the readOnly/openWorld annotations don't convey.

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

Conciseness2/5

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

It's a ~500-word wall of run-on guidance that redundantly restates schema descriptions (negation, recency mapping, company slugs). Front-loaded first two sentences are strong, but the remainder is unstructured and many sentences do not earn their place by adding anything beyond the schema.

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

Completeness4/5

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

All 19 parameters are documented and it exposes the map-scope default, widening behavior, and anonymous access — enough for correct invocation, and an output schema exists so return values need no explanation. It is arguably over-complete rather than lacking, which keeps it just under 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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

At 100% schema coverage the baseline is 3, but the description adds genuinely additive rules: the 'visa_sponsorship set + no posted_within_days → skip the 7-day default' rule and city radius guidance ('25-50 for a city'). Much of the rest restates schema text (dash-negation, recency mapping), so it lands at 4 rather than higher.

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

Purpose5/5

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

Opening sentence states a specific verb and resource: it 'opens the Worklittle jobs MAP for a place and an optional role,' and explicitly contrasts itself with 'a list of jobs.' The role (map-based job search) is unambiguous versus siblings like get_job_details or search_companies.

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

Usage Guidelines5/5

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

Explicitly says 'Call it whenever they want Worklittle jobs' and how to route multi-metro vs. near_* intent, when to omit place fields, and how to interpret umbrella phrases. It also states a fallback when an include-company filter returns zero. This is about as complete as usage guidance gets.

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

All Worklittle Jobs 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.

Resources

Need Help?