Skip to main content
Glama

add_application

Track a job jobwatch didn’t find—such as a referral or recruiter lead—as an application or queued role so all applications stay in one place.

Instructions

Add a job jobwatch didn't find (a referral, a recruiter, LinkedIn...), so everything is in one place: an application (only after the person has applied themselves), or status queued for one they're considering. A url to one job on Greenhouse, Lever, Ashby, Workable, Workday, Rippling, Google Careers (a .../jobs/results/ link), amazon.jobs (a .../jobs/ link), Oracle Recruiting Cloud (an ...oraclecloud.com/.../sites//job/ link), SmartRecruiters (a jobs.smartrecruiters.com// link), an Avature portal (a .../JobDetail// link) or iCIMS (a .../jobs///job link) or Jobvite (a jobs.jobvite.com//job/ link) is read in full (company and title may be left out). A LinkedIn job link is never read (LinkedIn's robots.txt disallows it): give company and title with it (and text to score it), and it's tracked on the company's own board when the same job is found there. Otherwise give company and title, and text (the posting, pasted) so it can be scored. For a job jobwatch already tracks (it came from get_digest or get_job), use mark_job instead; for the jobs in job-alert emails, import_job_alerts. When it's (maybe) the same opening as one already applied to, queued or skipped, the reply ends with that warning: tell the person.

Input Schema

NameRequiredDescriptionDefault
urlNoA link to the job: Greenhouse, Lever, Ashby, Workable, Workday, Rippling, Google Careers, amazon.jobs, Oracle Recruiting Cloud, SmartRecruiters, Avature, iCIMS, Jobvite or LinkedIn are read in full; any other link is just kept.
noteNoA note: who referred them, how they found it...
textNoThe posting's text, pasted, when the link can't be read, so it can be scored and prepped.
titleNoThe job title; may be left out when url is a job link it can read.
statusNoapplied (the default; only once the person has applied themselves), queued for one they're considering, or a later stage such as interviewing.applied
companyNoThe company; may be left out when url is a job link it can read.
follow_upNoA day: YYYY-MM-DD, or +N for N days from today. An empty string clears it.
next_stepNoWhat happens next ("hiring manager call Friday").
applied_onNoThe day applied (YYYY-MM-DD), if not today.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.6.0
    • changedInput schema / properties / url / description
      Previous value: -"A link to the job: Greenhouse, Lever, Ashby, Workable, Workday, Rippling, Google Careers, amazon.jobs, Oracle Recruiting Cloud, SmartRecruiters, Avature, iCIMS or LinkedIn are read in full; any other link is just kept."New value: +"A link to the job: Greenhouse, Lever, Ashby, Workable, Workday, Rippling, Google Careers, amazon.jobs, Oracle Recruiting Cloud, SmartRecruiters, Avature, iCIMS, Jobvite or LinkedIn are read in full; any other link is just kept."
  2. Changed1 schema field changedv0.5.0
    • changedInput schema / properties / url / description
      Previous value: -"A link to the job: Greenhouse, Lever, Ashby, Workable, Workday, Rippling or LinkedIn are read in full; any other link is just kept."New value: +"A link to the job: Greenhouse, Lever, Ashby, Workable, Workday, Rippling, Google Careers, amazon.jobs, Oracle Recruiting Cloud, SmartRecruiters, Avature, iCIMS or LinkedIn are read in full; any other link is just kept."
  3. Changed9 schema fields changedv0.2.3
    • addedInput schema / properties / applied_on / description
      Added value: +"The day applied (YYYY-MM-DD), if not today."
    • addedInput schema / properties / company / description
      Added value: +"The company; may be left out when url is a job link it can read."
    • addedInput schema / properties / follow_up / description
      Added value: +"A day: YYYY-MM-DD, or +N for N days from today. An empty string clears it."
    • addedInput schema / properties / next_step / description
      Added value: +"What happens next (\"hiring manager call Friday\")."
    • addedInput schema / properties / note / description
      Added value: +"A note: who referred them, how they found it..."
    • addedInput schema / properties / status / description
      Added value: +"applied (the default; only once the person has applied themselves), queued for one they're considering, or a later stage such as interviewing."
    • addedInput schema / properties / text / description
      Added value: +"The posting's text, pasted, when the link can't be read, so it can be scored and prepped."
    • addedInput schema / properties / title / description
      Added value: +"The job title; may be left out when url is a job link it can read."
    • addedInput schema / properties / url / description
      Added value: +"A link to the job: Greenhouse, Lever, Ashby, Workable, Workday, Rippling or LinkedIn are read in full; any other link is just kept."
  4. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing that certain ATS links are parsed in full while LinkedIn is never fetched (robots.txt), that company/title may be omitted when a readable link is supplied, and that the reply ends with a duplicate warning that should be relayed to the user. This is exactly the operational behavior an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose, but the long parenthetical enumerating ATS URL shapes duplicates the url parameter description and makes the prose dense and hard to scan. Some of that detail could be trimmed without losing routing value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 9 optional params, an output schema, and annotations, the description covers the decision points (which source, which sibling, duplicate handling, LinkedIn limitation) an agent needs. Minor gap: it doesn't say what the returned warning or created application looks like, though the output schema likely handles that.

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 baseline is 3, but the description adds cross-parameter dependencies the schema does not spell out: company and title are optional only when the URL is a readable job link, and text is needed otherwise so the posting can be scored. The link-format parentheticals largely restate the url 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 verb and resource with scope: 'Add a job jobwatch didn't find (a referral, a recruiter, LinkedIn...)', and immediately contrasts with jobs jobwatch already tracks. An agent can distinguish this from mark_job and import_job_alerts from the description alone.

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 routes: 'For a job jobwatch already tracks (it came from get_digest or get_job), use mark_job instead; for the jobs in job-alert emails, import_job_alerts.' It also clarifies the status semantics (applied only after the person applied). Alternatives and conditions are named, not implied.

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