Chatrabajo

Search open jobs

search_jobs

Read-onlyIdempotent

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.

Input Schema

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

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.2/5.0

Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines4/5

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.

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?