Remote MCP server to run your Atako AI agents: chat, projects, files, integrations and channels.
- Passed: Handshake
- Passed: Tools listed
- Passed: Updated recently
Median latency 132 ms · Last checked
Explore
Evidence for your next connection.
Independent measurements of remote MCP servers. Every observation has a timestamp.
Read-only probesMCP server · Code & DevOps
Find jobs near you. Search over 4 million openings by role, place, pay, visa and more.
4 failed · 8 not measured
Median of successful probes over 7 days
Share of countable probes over 30 days, including daily rollups. Auth challenges are excluded.
Tool definitions returned by this server
Independent monitoring
Responded
The server completed its last measured handshake. This is an observation, not a guarantee.
Last checked| Test area | Passed | Failed | Unmeasured |
|---|---|---|---|
ConnectionCan a client connect and discover tools? | 4 | 1 | 0 |
Reliability & speedDoes it respond consistently and quickly? | 0 | 0 | 4 |
Access & authenticationWhat is required to use this server? | 1 | 0 | 2 |
Tool qualityAre the tool definitions usable by an agent? | 3 | 1 | 0 |
Publisher identityCan the publisher be traced to its source? | 2 | 2 | 2 |
Unmeasured means there is not enough evidence to decide. How these checks work
Start using Worklittle Jobs
Choose your client, copy the configuration, then enable the server in your client’s MCP settings.
Run this command in your terminal, then restart Claude Code.
Claude Code
claude mcp add --transport http worklittle-jobs https://mcp.worklittle.com/Capabilities
Jobs — Apply to a job for the user: Worklittle fills out and submits the application in a browser. Pass job_id from search_jobs. For a Worklittle-hosted posting also include name, email and resume. It submits by default; pass auto_submit false when the user wants to review first, then show them the answers from check_application_status and send it with submit_application only after they say so.
DiscoveredJobs — Check an application Worklittle is filling out: its status, which form fields are filled, and a live view link. Only the status completed means it was submitted.
DiscoveredJobs — Delete the user's main resume from their profile. Other saved resumes stay.
DiscoveredJobs — Get the user's apply settings: auto_apply (Worklittle applies to matching jobs on its own), auto_submit (submit without a review stop) and tailor_resume (tailor the resume to each job).
DiscoveredJobs — Fetch detailed information about a specific job, including full responsibilities, qualifications, and company details. Pass job_id from search_jobs when you have one. If the user asks for full details of a role without an id (e.g. the first software engineer job in Austin), pass query and optional location instead — the tool loads the first matching live listing.
DiscoveredJobs — Returns aggregate job-market statistics from Worklittle. Call with no args for the full indexed market (counts, workplace mix, top hiring companies). When the user names a role and/or city (e.g. product managers in San Francisco), pass query and location. The filtered slice includes match count, top companies in the sample, and salary signals from listings that publish pay.
DiscoveredJobs — Get the user's Worklittle profile (name, location, contact details and job preferences). If they have not linked their account it returns connected false; use get_my_resume or apply_for_job to sign them in.
DiscoveredJobs — Get the user's main resume: its status (ready, processing or missing) and, when ready, the resume text and profile details read from it. Use it to tailor advice or an application to the user's real experience.
DiscoveredJobs — List the user's applications that Worklittle is filling out right now (queued, running, or waiting on the user), with job_id and session_id. Use it to find which one to stop or check.
DiscoveredJobs — List applications: pending ones (matched by auto-apply, waiting for approval, running, or waiting on the user) and finished ones (completed = submitted, failed, stopped). Check it before applying so the same job is never applied to twice. Filter with status (pending, applied, ...), job_id or applicant_id.
DiscoveredJobs — List the user's recent Worklittle chats (title and status) for the app sidebar.
DiscoveredJobs — Sign the user out of Worklittle in this app.
DiscoveredJobs — Create a sign-in link so the Worklittle app can open the user's chats on worklittle.com.
DiscoveredJobs — Save standing facts about the user that Worklittle's Apply with AI uses on every future application: work authorization and visa sponsorship by country, relocation, notice period, desired salary, languages, qualifications, who referred them, or other standing answers they ask applications to use. Stored as the 'More about you' text in their Settings. Pass the complete text to keep (read get_my_profile first and merge with what is there, so nothing is lost). Write it in the user's words; never invent facts.
DiscoveredJobs — Search the Worklittle market company index by name or slug (ranked typeahead). Returns id, name, slug, logo_url, and enrichment fields for employers with open jobs. Use when the user names an employer and you need a real slug/id for search_jobs company= filters, job alerts, or automations. If zero hits, try alternate spellings or related employer names from further search_companies calls — do not invent company ids or slugs. If still empty, tell the user that employer is not in the index yet and offer any close matches you found.
DiscoveredJobs — 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).
DiscoveredJobs — Change what an application in progress fills in, without stopping it. Use when the user says something about an application Worklittle is filling right now ("say my notice period is one month", "my friend Ana Ruiz referred me", "I need visa sponsorship for the US", "make that answer shorter"). Pass their wish as plain instructions with their exact facts; never add facts. Works while the application is running, ready to submit, or waiting for answers. Needs the session_id from apply_for_job or list_active_applications. For facts that should apply to every future application too, also call save_about_me.
DiscoveredJobs — Stop an application that Worklittle is filling out for the user. This cancels the application in progress and it cannot be resumed; the user would have to start it again. Needs the session_id from apply_for_job or list_active_applications.
DiscoveredJobs — Send an application that stopped for review (apply_for_job with auto_submit false, status awaiting_submit). Call it only after the user has seen the answers from check_application_status and said to send it.
DiscoveredJobs — Add a job to the user's Applied or Saved list, or change its status, so they can find it later.
DiscoveredJobs — Turn auto_apply, auto_submit or tailor_resume on or off. Only send the settings to change. Turning auto_apply on needs Instant or a card on file.
DiscoveredJobs — Update the user's Worklittle profile, such as name, location, phone, links or the kind of job they want. Only send the fields to change.
DiscoveredJobs — Save the resume the user attached in the chat (PDF, Word, text or image) as the main resume on their Worklittle profile so it can be used to apply. It replaces the current main resume; other saved resumes (an account keeps up to 5) stay. Pass the attached file as resume_file.
DiscoveredRecent measurements
| Checked | Result | Response | Tools |
|---|---|---|---|
| Connected | 58 ms | 23 |