Skip to main content
Glama

Joeb

Like, dismiss or mark jobs applied

update_jobs
Idempotent

Record the user's decisions on jobs, many in one call: like them, dismiss them, mark them applied.

A job carries two independent pieces of state, and each list sets one without touching the other. liked and dismissed set the first on a job that has neither, and never overwrite it: a job already dismissed can't be liked here, nor a liked one dismissed. To change a like or dismissal, clear it with clear_jobs first. Liking a liked job, or dismissing a dismissed one, is fine. applied sets the second, so marking a liked job applied keeps the like, and dismissing an applied job keeps it applied. A job may be in applied and also in liked or dismissed, which sets both. A job in both liked and dismissed contradicts itself: the call fails and nothing is changed. A job named twice in one list, by any of its ids, counts once.

Each list is optional, but the call names at least one job and at most 100 across the three lists. Name each job by its id as a row shows it (its first 12 characters), by any unique prefix of 8 or more characters, or by its full id. A posting link is not an id here: get_jobs looks one up.

All or nothing: every id is checked before anything is written. If any id names no job, matches several jobs, or isn't a job id, nothing is changed and the error names each bad id, listing a longer id for every job an ambiguous one matches. If any job already has the other decision (a liked job in dismissed, a dismissed job in liked), nothing is changed either, the applied list included, and the error names each such job with its current decision, to clear with clear_jobs first.

Liked jobs show up in the user's Joeb web app, where the browser extension can fill in the application. Every job the user liked, dismissed or applied to is left out of later searches, so after deciding on a page of results, run the same search again for the next matches. clear_jobs undoes any of these decisions.

Returns, for each list, how many jobs it named and which of them were already in that state before this call, and, when liked named a job, a last line giving the Liked page's address.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "update_jobs"
  }
}

Input Schema

NameRequiredDescriptionDefault
likedNoJobs the user likes. A job already dismissed can't be liked here: clear its dismissal with clear_jobs first.
appliedNoJobs the user has applied to. Their liked or dismissed status stays as it is.
dismissedNoJobs the user is not interested in. A job already liked can't be dismissed here: clear its like with clear_jobs first.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only declare idempotentHint=true, destructiveHint=false and readOnlyHint=false, but the description explains the far more consequential semantics: all-or-nothing validation (nothing is written if any id is bad or conflicts), the two independent state axes, the 100-job cap, and multi-field error payloads naming each bad id. It is also consistent with the idempotency hint by noting that liking a liked job 'is fine'.

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?

Front-loaded with the purpose, and nearly every sentence carries load-bearing rules. However, the density is high and some clauses are hard to parse (e.g. 'liked and dismissed set the first on a job that has neither'), and the all-or-nothing paragraph partly restates the conflict rule already given.

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?

Despite no output schema, the description explains the return payload (per-list counts, which jobs were already in that state, and the Liked page address), plus capacity, error reporting, and downstream search effects — everything needed to invoke it correctly and interpret the result.

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

Parameters5/5

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

Schema coverage is already 100%, yet the description still adds essential meaning: mutual exclusivity of liked and dismissed (with the failure mode), the independence of applied from both, accepted id forms (first 12 characters, unique prefix of 8+, full id), rejection of posting links, and duplicate-counts-once behavior.

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?

Opens with a specific verb and resource ('Record the user's decisions on jobs, many in one call') and immediately names the three operations it covers (like, dismiss, mark applied), distinguishing it from clear_jobs and get_jobs, which the description explicitly routes to elsewhere.

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 states the alternative and condition: to change an existing like or dismissal, 'clear it with clear_jobs first', and to turn a posting link into an id, 'get_jobs looks one up'. It also gives a workflow rule — after deciding on a page of results, 'run the same search again' since decided jobs are excluded from later searches.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources