Skip to main content
Glama
FreeApply

FreeApply

Official
by FreeApply
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
JavaScript
Local

Get clearance to submit

freeapply_clear_to_submit

Checks submission pace, user limits, and unattended-run budgets before applying to one job, then returns clearance or refusal so you know whether to submit now.

Instructions

Gives the go-ahead for one submit after checking the pace, the user's limits and, in an unattended run, its budgets. Unlike freeapply_update_job, which records the submit afterwards, it comes right before it; recording applied is refused without its clearance. Use it right before every submit, with the job_id. Not early, and not for a job you won't submit now: each clearance counts toward the per-minute pace at once. Behavior: allows at most 3 submissions a minute (or the user's slower setting), keeps the user's daily cap and, for easy_apply, whether the user allows one-click apply. A clearance is for one job, lasts 15 minutes and is used up when freeapply_update_job records applied; asking again for the same job issues a new one. Clearances last only while FreeApply runs. Parameters: job_id gets the clearance; without it you only see the pace. method (default external) matters only for easy_apply, refused while one-click apply is off. run_id, in an unattended run, first checks that run's time and application budgets and the dashboard's Stop button. Returns: {clear, advice, last_minute, limit_per_minute, today, daily_cap}, plus clearance {job_id, expires_at} when clear. clear false: don't submit; prepare the next job and call again later. refused: one-click apply is off; apply on the employer's site or skip the job. stop_run true, with reason: the run must end now; call freeapply_autorun action finish.

Input Schema

NameRequiredDescriptionDefault
job_idNoThe job about to be submitted.
methodNoHow you will submit: external (an employer or ATS form; default), easy_apply (a job board's one-click apply) or email.
run_idNoIn an unattended run only: the run_id that freeapply_autorun start returned.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.2

TDQS

A5/5.0
Behavior5/5

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

Discloses important stateful behavior beyond annotations: per-minute pace, daily cap, one-click apply restriction, 15-minute clearance lifetime, single-use clearance consumed by update_job, and that new requests issue new clearances. It also explains that clearances only last while FreeApply runs and what run_id budget/Stop checks imply.

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?

The description is dense but appropriately sized for a stateful, policy-driven tool. It is front-loaded with purpose and sibling contrast, then proceeds through usage, behavior, parameters, and return/action handling without wasted sentences.

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?

Although there is no output schema, the description explains the return fields and how to interpret clear false, refused, and stop_run true. Combined with the schema and annotations, it gives an agent enough information to invoke and react to the tool correctly.

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?

Even though schema description coverage is 100%, the description adds meaningful semantics: job_id is what gets the clearance and without it only the pace is shown; method defaults to external and matters only for easy_apply; run_id is for unattended runs and triggers budget and Stop-button checks.

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: gives clearance to submit one job right before submission. It explicitly distinguishes itself from freeapply_update_job by explaining that update_job records the submit afterwards and is refused without this clearance.

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 timing guidance: use right before every submit with job_id, not early, and not for a job you will not submit now. It also explains what to do when clear is false, when refused due to one-click apply being off, and when stop_run is true with a required follow-up call.

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

Deploy Server

Other Tools