Skip to main content
Glama

Apply to Job

aiapplyd_apply
Destructive

Apply to one job on the user's behalf. Pass job_match_id from aiapplyd_get_matches, or job_url for any posting. AI Applyd rewrites the resume and cover letter for that role, then completes and submits the application on the employer's own…

Instructions

Apply to one job on the user's behalf. Pass job_match_id from aiapplyd_get_matches, or job_url for any posting. AI Applyd rewrites the resume and cover letter for that role, then completes and submits the application on the employer's own hiring system (Workday, Greenhouse, Lever, Ashby, iCIMS and the other major ATS platforms). mode "auto" submits with no review step; mode "review" prepares everything and holds it for the user's approval; omit mode to follow the review setting on the user's account. The mode applies to this one application and never changes the user's settings. Spends one of the user's applications and AI credits, and a submitted application cannot be withdrawn, so apply only to jobs the user chose. Returns the application id and a tracking link; when the job already has an application, that one comes back with alreadyExisted true instead of a second. On a timeout or an error, call aiapplyd_get_applications before retrying, and never re-apply by job_url to a job already applied to by job_match_id. Do not use it to save or skip a match; use aiapplyd_triage_matches. Next: aiapplyd_get_applications to follow it, and aiapplyd_review_application if it waits for approval.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNo"auto" submits with no review step. "review" holds the prepared application for the user's approval. Omit to follow the user's account setting. Applies to this application only.
job_urlNoURL of any job posting to apply to (e.g. "https://boards.greenhouse.io/acme/jobs/123"). Pass this OR job_match_id.
job_match_idNoThe job_match_id of a match from aiapplyd_get_matches (e.g. 48213). Pass this OR job_url.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
jobUrlYes
statusYesOur own record. Never proof the employer received it.
companyYes
outcomeYesstarted: a new application; already_in_progress: this job already had one (alreadyExisted); not_confirmed: the user declined, nothing was sent.
jobTitleYes
jobMatchIdYes
trackingUrlYes
recordedModeYes
applicationIdYesThe application to follow with aiapplyd_get_applications. Null only when nothing was started.
requestedModeYes
alreadyExistedYesTrue when this job already had an application, which is returned instead of a second one.
preparationStatusYes
preparedUnderFreeWatchYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed18 schema fields changedv1.8.5
    • removedOutput schema / properties / applicationId / anyOf
      Removed value: -[
      -  {
      -    "type": "number"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / applicationId / type
      Added value: +[
      +  "number",
      +  "null"
      +]
    • removedOutput schema / properties / company / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / company / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / jobMatchId / anyOf
      Removed value: -[
      -  {
      -    "type": "number"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / jobMatchId / type
      Added value: +[
      +  "number",
      +  "null"
      +]
    • removedOutput schema / properties / jobTitle / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / jobTitle / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / jobUrl / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / jobUrl / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / preparationStatus / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / preparationStatus / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / recordedMode / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / recordedMode / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / status / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / status / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / trackingUrl / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / trackingUrl / type
      Added value: +[
      +  "string",
      +  "null"
      +]
  2. Addedv1.8.0

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare destructive/non-idempotent/open-world, and the description adds materially beyond that: it spends an application and AI credits, submitted applications cannot be withdrawn, alreadyExisting applications return with alreadyExisted true instead of duplicating, and the retry protocol on timeout ('call aiapplyd_get_applications before retrying'). These are exactly the consequences an agent must know before acting.

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 core action, then costs, then recovery guidance, then routing to siblings. It is fairly long and repeats the mode explanation that the schema already carries, but almost every sentence contributes operational value rather than filler.

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 the return format being covered by an output schema, the description surfaces the important return cases (application id, tracking link, alreadyExisted) and the failure path. For a destructive, credit-consuming, one-shot operation, nothing an agent needs to act safely 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 all three parameters are already documented, including the mode enum and the job_url/job_match_id exclusivity. The description restates the mode behavior and the match-id/url source, adding context but little that isn't already in the schema. Baseline 3 is appropriate.

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 ('Apply to one job on the user's behalf') with the scope ('one job') that implicitly separates it from a bulk apply flow, and names the ATS platforms involved. It does not explicitly name the sibling aiapplyd_auto_apply, which is the closest potential confusion, so differentiation relies partly on inference.

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 input routing (pass job_match_id from aiapplyd_get_matches, or job_url), mode semantics with the account-setting fallback, an explicit exclusion ('Do not use it to save or skip a match; use aiapplyd_triage_matches'), and follow-up tools. An agent has everything needed to choose this tool and invoke it correctly.

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