Skip to main content
Glama

Start or finish an auto-run

freeapply_manage_autorun

Starts and finishes each auto-run applying session so FreeApply keeps applying on its own, waiting for due runs and releasing them without a scheduled task.

Instructions

Keeps FreeApply applying on its own from this session, with no scheduled task: start waits until something is due, finish ends a run (freeapply_get_status only shows the run state). Use: auto-run mode of freeapply-apply, which setup's last step enters: start with wait (takeover on the first call), finish after each run, then start again. Not in a session the user runs by hand. Behavior: start with wait holds the call up to 10 minutes while nothing is due (auto-run stopped by the user's Stop or a limit in Settings, the rest after a search found nothing new, the daily cap) and returns as soon as something is, within seconds of the user pressing Start. One session runs it at a time. A run checks in with each job-work tool call and freeapply_clear_to_submit (15 minutes without one counts as ended); freeapply_clear_to_submit with the run_id ends it at a hard stop. finish releases the run and starts the rest (autorun.every_hours), or none when the user asked for a restart with new settings; harmless on a run that already ended. Parameters: action start or finish. wait (start): hold as above; without it start answers at once. takeover (start with wait): only on the call right after the user asked for setup or to keep applying: it presses Start (clears a Stop, a reached limit and the rest) and makes this session the runner; the session it replaced gets replaced at its next start. run_id (finish): the run start returned. summary (finish): one line shown in the dashboard's run history. Returns: start {go: true, run_id, minutes (left before the time limit, null: none), max_applications, sites}; {go: false, replies_due: true}: do freeapply-replies, then start again; {go: false, needs_user: terms|setup}: ask the user (freeapply_open_dashboard), freeapply_get_status with wait, then start again; {go: false, wait_again: true}: start again; {go: false, replaced: true} or any other go false: end quietly. finish {finished, applied_this_run}, null for a run no longer active. Errors: finish without run_id; an action other than start or finish.

Input Schema

NameRequiredDescriptionDefault
waitNoFor start in auto-run mode: hold until something is due.
actionYesstart a run (with wait: when one is due); finish it.
run_idNoRequired for finish.
summaryNoFor finish: e.g. "applied 4, needs you 2" (up to 500 characters).
takeoverNoFor start with wait: the call right after the user asked to start.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.6

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond annotations by describing the 10-minute wait behavior, takeover semantics, single-runner constraint, check-in requirements, hard-stop behavior via freeapply_clear_to_submit, and finish scheduling. These are critical stateful behaviors for an agent orchestrating the auto-run loop.

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?

The description is long and dense, but it is structured into purpose, usage, behavior, parameters, returns, and errors. Most sentences carry necessary state-machine semantics, though some parentheticals could be tightened without losing meaning.

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?

Covers the full control flow for a complex stateful tool: expected returns for go true/false branches, needs_user handling, replaced/wait_again cases, finish return values, and error conditions. With no output schema, this description provides the return semantics an agent needs.

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?

Although schema coverage is 100%, the description adds operational meaning: wait holds until something is due, without wait start answers immediately, takeover applies only to the call right after the user asked, run_id is from start, and summary appears in dashboard history. This materially supplements the terse schema descriptions.

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 workflow verb/resource: keeping FreeApply applying automatically via start/finish actions. It explicitly distinguishes itself from freeapply_get_status and from manual user-run sessions, so an agent can identify its role without opening the schema.

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?

Provides explicit usage sequencing: start with wait, finish after each run, then start again, as part of setup's auto-run mode. It also says when not to use it (a session the user runs by hand) and names freeapply_get_status as the state-only alternative.

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