Skip to main content
Glama

Claim or skip a job

freeapply_claim_job

Claims a job before you work on it: runs the duplicate check, applies your rules, starts tracking, and returns the job_id later calls need. Use it before opening any application form.

Instructions

Claims a job before you work on it: runs the duplicate check, applies the user's rules and starts tracking it, returning the job_id every later call needs. Unlike freeapply_list_jobs it adds a job, and unlike freeapply_update_job it makes the job's first record. Use it before opening any application form, and to record a job you reviewed and won't pursue (status skipped, with status_note) so it isn't reviewed again. Not for changing a job you already claimed. Behavior: adds the job unless, in this order: a posting id already tracked returns that job (existing: true; nothing added); a job site the user didn't choose, or one signed out or paused, is refused (refused says why, sites lists the ready ones); the same company and title as a job already applied to is refused as a repost; posted pay below the user's minimum is saved as skipped (rule: pay_floor). Parameters: title and company are required; company is the employer, not a staffing firm, when you can tell. Pass external_id whenever the site shows the posting's id: it catches reposts. url or source tells which job site it came from; the URL just read by freeapply_fetch_posting keeps its keywords. pay_min and pay_max feed the pay floor; fit_score is 0 to 100, as the apply procedure scores it. Returns: {job_id, existing, status, rule, earlier}. earlier lists up to 20 other jobs at the same company as {id, title, company, status, same_title}; if an applied one is clearly the same role under another title, mark this one skipped with freeapply_update_job. Errors: a missing title or company.

Input Schema

NameRequiredDescriptionDefault
urlNoThe posting's URL; also tells which job site it came from.
titleYesJob title, as posted.
sourceNoWhere it was found: a job site id (linkedin, indeed, company_sites, ...) or referral.
statusNofound to work on it (default), or skipped to record a job you won't pursue.
companyYesEmployer name, as posted (not the staffing firm's name, if known).
pay_maxNoHighest posted pay as a number.
pay_minNoLowest posted pay as a number: annual, or hourly if posted hourly.
locationNoLocation as posted.
pay_textNoPay exactly as posted, e.g. "$90k-$110k".
apply_urlNoWhere the application form is, if different.
fit_notesNoWhy it fits or doesn't, in one sentence.
fit_scoreNoFit from 0 to 100, scored as the apply procedure describes.
work_modeNoremote, hybrid or onsite, as posted.
descriptionNoShort description or key requirements.
external_idNoThe posting's id on its source site; finds the same posting again, reposts included.
status_noteNoWhy it was skipped, in one plain sentence; for status skipped.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.2

TDQS

A4.6/5.0
Behavior4/5

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

Goes well beyond annotations by explaining duplicate handling, site eligibility checks, repost detection, pay-floor skipping, return fields, and errors. Annotations already cover the safety profile, but the description still adds substantial behavioral context about ordering and side effects.

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-loads the core action, then organizes behavior, parameters, returns, and errors into clear labeled sections. It is dense and somewhat long, but most sentences carry operational value for a complex mutation tool.

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?

No output schema exists, but the description documents the return shape and the earlier list. Given the 16-parameter schema, annotations, and behavioral complexity, it provides enough context for an agent to call the tool correctly.

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 100%, so the baseline is 3; the description adds meaningful semantics for key parameters such as company vs. staffing firm, external_id for reposts, url/source for site origin, pay_min/pay_max feeding the pay floor, and fit_score range. It does not explain every one of the 16 parameters, but it adds useful meaning beyond the already-rich schema.

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?

States a specific action and resource: claims a job, runs duplicate checks, applies rules, starts tracking, and returns job_id. It explicitly distinguishes itself from freeapply_list_jobs and freeapply_update_job, so an agent can select it correctly.

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?

Gives explicit when-to-use guidance: before opening any application form, and for recording skipped jobs. It also states when not to use it—'Not for changing a job you already claimed'—and names the relevant alternative behavior.

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