Chatrabajo finds open, verified jobs in Argentina and Latin America, including remote jobs open to the region. Tell Chatrabajo what role you want, or share your CV, and it shows the jobs that fit, why each one fits, and the link to apply on the original posting.
Two read-only tools:
search_jobs: searches by role, location, work mode and seniority. It can also return only jobs found in the last few days, to check for new postings. match_jobs_to_cv: matches jobs to the job-relevant facts of a CV
Scored across 2 tools
Both tools return job matches for the same region and share the same 40-result pagination contract, so they are close cousins. However, the descriptions draw a usable line: match_jobs_to_cv takes de-identified CV facts, while search_jobs takes an explicit role/skill/location query and is explicitly flagged for when the user states what job they want. An agent can pick correctly with a little care, but the boundary is not razor-sharp.
Both names are snake_case with a leading action verb (match_, search_) and a job-oriented noun, so the convention is consistent. match_jobs_to_cv is a three-part phrase while search_jobs is the simpler verb_noun form, a minor structural deviation that doesn't hurt predictability much.
Two tools is thin for a job-matching service with two distinct entry points (CV-based and query-based). There's no tool for retrieving a specific job, refining results, or managing saved matches, so the surface feels under-built rather than well-scoped.
The core read path (find matching jobs, paginate via nextOffset) is covered for both input modes, which is the primary use case. But there are notable gaps: no get_job by id/details lookup, no structured way to page other than in-band offsets, and no saved-jobs or application-link follow-up operations, leaving agents with dead ends after listing.
Finds verified, currently open jobs in Argentina/LATAM that fit a CV the user shared. Read the CV yourself and pass only its job-relevant facts: current or target title, related roles, skills, location and a short professional summary, plus seniority only if the person states one. Returns up to 40 jobs at a time; when nextOffset isn't null, more jobs match, so tell the user and offer to show them. Never pass the person's name, email, phone number, address or ID numbers. Chatrabajo keeps only an anonymous record of the roles, location and work mode searched, never the summary or skills.
| Name | Required | Description | Default |
|---|---|---|---|
| roles | No | Other roles the CV qualifies for, including the usual names for the same job | |
| title | Yes | Current or target job title from the CV | |
| offset | No | Only to show more jobs: the nextOffset from the previous result, with the same criteria | |
| skills | No | Skills or tools, e.g. ["Excel", "Facturación"] or ["React", "TypeScript"] | |
| summary | No | Two or three sentences about experience and strengths, with no personal or contact details | |
| location | No | Where the person lives or wants to work, e.g. "Córdoba, Argentina". Defaults to Argentina. | |
| workMode | No | Only when the person states a preference | |
| maxResults | No | How many jobs to return, best first, at most 40. Only when the person asked for a few, e.g. 5. Leave it out to get up to 40 | |
| newWithinDays | No | Only jobs Chatrabajo found in the last N days. Use 1 in a daily scheduled task, so each run shows only new jobs. Leave it out to get every open job | |
| experienceLevel | No | Only when the person states a seniority. Leave it out to get every level |
| Name | Required | Description |
|---|---|---|
| jobs | Yes | |
| nextOffset | Yes | When more jobs match, the offset that gets the next ones with the same criteria. Null when these are all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses pagination semantics ('up to 40 jobs at a time; when nextOffset isn't null, more jobs match'), privacy constraints on the input ('never pass name, email, phone, address or ID numbers'), and exactly what the service retains ('anonymous record of roles, location and work mode, never the summary or skills'). The annotations only cover the safe-read profile, so this added context is genuinely valuable.
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, followed by usage, pagination, and privacy guidance. It is dense but every clause carries information; it reads as one long block rather than being broken into scannable segments, which slightly hurts structure.
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 10-parameter, 1-required tool with an output schema, the description covers what the output schema cannot: pagination behavior via nextOffset and privacy/data-retention constraints. Nothing an agent needs in order to call this 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 description coverage is 100%, so every parameter is already documented in the schema (including enums for workMode and experienceLevel). The description restates the field set (title, roles, skills, location, summary, seniority) but adds little syntax or format meaning beyond what the schema already provides, so 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?
States a specific verb and resource plus scope: 'Finds verified, currently open jobs in Argentina/LATAM that fit a CV the user shared.' An agent immediately knows this is a CV-driven job matcher rather than a generic search. It does not name or distinguish itself from the sibling search_jobs, so the differentiation is left implicit.
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 for use ('fit a CV the user shared') and instructs the agent to read the CV itself and extract only job-relevant facts, including conditional guidance (seniority only if stated). It never names search_jobs or states when NOT to use this tool, so there is no explicit alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches verified, currently open jobs for a job seeker in Argentina/LATAM by role, skills, location and work mode. Returns the strongest matches, up to 40 at a time, each with why it matches and the link to apply. When nextOffset isn't null, more jobs match: tell the user and offer to show them. A job's title must match one of the roles, so include the usual names for the same job. Use it when the user says what kind of job they want. Chatrabajo keeps an anonymous record of the roles, location and work mode searched.
| Name | Required | Description | Default |
|---|---|---|---|
| roles | Yes | Job titles the person wants plus the usual names for the same job, e.g. ["Product Designer", "UX Designer", "UI Designer", "UX/UI Designer"] or ["Asistente administrativa", "Auxiliar administrativo"] | |
| offset | No | Only to show more jobs: the nextOffset from the previous result, with the same criteria | |
| skills | No | Skills or tools, e.g. ["Excel", "Facturación"] or ["React", "TypeScript"] | |
| location | No | Where the person lives or wants to work, e.g. "Córdoba, Argentina". Defaults to Argentina. | |
| workMode | No | Only when the person states a preference | |
| maxResults | No | How many jobs to return, best first, at most 40. Only when the person asked for a few, e.g. 5. Leave it out to get up to 40 | |
| newWithinDays | No | Only jobs Chatrabajo found in the last N days. Use 1 in a daily scheduled task, so each run shows only new jobs. Leave it out to get every open job | |
| requiredSkills | No | Only skills the person said are a must | |
| experienceLevel | No | Only when the person states a seniority. Leave it out to get every level | |
| excludedCompanies | No |
| Name | Required | Description |
|---|---|---|
| jobs | Yes | |
| nextOffset | Yes | When more jobs match, the offset that gets the next ones with the same criteria. Null when these are all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only/idempotent/non-destructive safety profile, but the description adds traits they cannot express: a 40-result cap per call, how nextOffset drives follow-up paging, and the side-effect that 'Chatrabajo keeps an anonymous record of the roles, location and work mode searched'. The data-retention disclosure in particular is meaningful behavioral context.
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 and scope lead, matching and paging rules follow, and each sentence carries a distinct instruction with no filler. Even the closing privacy note supplies information not available anywhere else in the structured fields.
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 10-parameter, read-only search with 90% schema coverage, an output schema, and full safety annotations, the definition still covers scope, matching rules, result shape, result cap, and pagination follow-up. 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 90%, so most parameters are self-documenting and the baseline is 3. The description still adds genuine semantics beyond the schema with 'A job's title must match one of the roles, so include the usual names for the same job' (matching behavior) and the rule that offset must be paired with 'the same criteria' from the prior result.
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 verb (searches) and resource (verified, currently open jobs) with explicit scope ('for a job seeker in Argentina/LATAM by role, skills, location and work mode') and defines what a result contains. It does not, however, distinguish itself from its sibling match_jobs_to_cv, so an agent must infer whether role/skill search or CV matching is the right entry point.
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 it when the user says what kind of job they want' gives clear triggering context, and the description adds real operational guidance around paging ('When nextOffset isn't null... tell the user and offer to show them'). It stops short of naming when NOT to use it or pointing to match_jobs_to_cv as the alternative when a CV is available.
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.
match_jobs_to_cv6 fields changedInput schema / properties / maxResults / defaultRemoved value: -50Input schema / properties / maxResults / descriptionPrevious value: -"How many jobs to return at most, best first. Only when the person asked for a few, e.g. 5. Leave it out to get every strong match, up to 50"New value: +"How many jobs to return, best first, at most 40. Only when the person asked for a few, e.g. 5. Leave it out to get up to 40"Input schema / properties / maxResults / maximumPrevious value: -50New value: +9007199254740991Input schema / properties / offsetAdded value: +{
+ "default": 0,
+ "description": "Only to show more jobs: the nextOffset from the previous result, with the same criteria",
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+}Output schema / properties / nextOffsetAdded value: +{
+ "description": "When more jobs match, the offset that gets the next ones with the same criteria. Null when these are all",
+ "type": [
+ "integer",
+ "null"
+ ]
+}Output schema / requiredPrevious value: -[
- "jobs"
-]New value: +[
+ "jobs",
+ "nextOffset"
+]search_jobs6 fields changedInput schema / properties / maxResults / defaultRemoved value: -50Input schema / properties / maxResults / descriptionPrevious value: -"How many jobs to return at most, best first. Only when the person asked for a few, e.g. 5. Leave it out to get every strong match, up to 50"New value: +"How many jobs to return, best first, at most 40. Only when the person asked for a few, e.g. 5. Leave it out to get up to 40"Input schema / properties / maxResults / maximumPrevious value: -50New value: +9007199254740991Input schema / properties / offsetAdded value: +{
+ "default": 0,
+ "description": "Only to show more jobs: the nextOffset from the previous result, with the same criteria",
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+}Output schema / properties / nextOffsetAdded value: +{
+ "description": "When more jobs match, the offset that gets the next ones with the same criteria. Null when these are all",
+ "type": [
+ "integer",
+ "null"
+ ]
+}Output schema / requiredPrevious value: -[
- "jobs"
-]New value: +[
+ "jobs",
+ "nextOffset"
+]match_jobs_to_cv1 field changedInput schema / properties / maxResultsAdded value: +{
+ "default": 50,
+ "description": "How many jobs to return at most, best first. Only when the person asked for a few, e.g. 5. Leave it out to get every strong match, up to 50",
+ "maximum": 50,
+ "minimum": 1,
+ "type": "integer"
+}search_jobs1 field changedInput schema / properties / maxResultsAdded value: +{
+ "default": 50,
+ "description": "How many jobs to return at most, best first. Only when the person asked for a few, e.g. 5. Leave it out to get every strong match, up to 50",
+ "maximum": 50,
+ "minimum": 1,
+ "type": "integer"
+}match_jobs_to_cvsearch_jobs
Add one secure layer between your agents and this server.