Chatrabajo

Match open jobs to a CV

match_jobs_to_cv

Read-onlyIdempotent

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.

Input Schema

Name	Required	Description
`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

Output Schema

Name	Required	Description	Default
`jobs`	Yes
`nextOffset`	Yes	When more jobs match, the offset that gets the next ones with the same criteria. Null when these are all

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedOct 16, 2026

removedInput schema / properties / maxResults / default
```
Removed value: -50
```

changedInput schema / properties / maxResults / description

Previous 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"

changedInput schema / properties / maxResults / maximum
```
Previous value: -50New value: +9007199254740991
```

addedInput schema / properties / offset

Added 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"
+}

addedOutput schema / properties / nextOffset

Added 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"
+  ]
+}

changedOutput schema / required

Previous value: -[
-  "jobs"
-]New value: +[
+  "jobs",
+  "nextOffset"
+]

Changed1 schema field changedOct 16, 2026

addedInput schema / properties / maxResults

Added 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"
+}

First observedOct 7, 2026

TDQS

A4.1/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

All Chatrabajo 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?