Skip to main content
Glama
FreeApply

FreeApply

Official
by FreeApply
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
JavaScript
Local

Start or finish an unattended run

freeapply_autorun

Starts and finishes unattended scheduled job-application runs, records the schedule, and reports when it is created or removed.

Instructions

Starts and finishes unattended (scheduled) runs, and records the schedule. Unlike freeapply_status, which only shows the run state, it changes it; the schedule itself is a scheduled task in the user's AI app. Use start at the beginning of every scheduled run and finish at its end, also when stopping early. Use schedule_created or schedule_removed after you create or delete the scheduled task, so the dashboard shows it. Not in a session the user runs by hand. Behavior: start opens a run only when one may go now; another start while a run is going, or within 10 minutes of its planned end, gets go false. During the run, freeapply_clear_to_submit with the run_id ends it when a budget runs out or the user presses Stop. finish releases the run; finishing a run that already ended is harmless. Parameters: action picks the step. finish needs the run_id from start and takes summary, one line on the run, e.g. "applied 4, needs you 2" (up to 500 characters). Returns: start {go: true, run_id, minutes, max_applications, sites}, or {go: false, reason} (auto-run off, Terms or setup missing, daily cap reached, or another run going); then stop at once, quietly. finish {finished, applied_this_run}, null for a run no longer active. schedule_created and schedule_removed {schedule_created}. Errors: finish without run_id, or another action.

Input Schema

NameRequiredDescriptionDefault
actionYesstart or finish a run, or report the scheduled task.
run_idNoFor finish: the run_id that start returned.
summaryNoFor finish: one line on the run.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.0.2
    • changedInput schema / properties / action / description
      Previous value: -"What to do."New value: +"start or finish a run, or report the scheduled task."
    • changedInput schema / properties / action / enum
      Previous value: -[
-  "start",
-  "check",
-  "finish",
-  "schedule_created",
-  "schedule_removed"
-]New value: +[
+  "start",
+  "finish",
+  "schedule_created",
+  "schedule_removed"
+]
    • changedInput schema / properties / run_id / description
      Previous value: -"The run_id that start returned; needed for check and finish."New value: +"For finish: the run_id that start returned."
    • changedInput schema / properties / summary / description
      Previous value: -"One-line summary, for finish."New value: +"For finish: one line on the run."
  2. Changed4 schema fields changedv1.0.1
    • addedInput schema / properties / action / description
      Added value: +"What to do."
    • addedInput schema / properties / action / enum
      Added value: +[
+  "start",
+  "check",
+  "finish",
+  "schedule_created",
+  "schedule_removed"
+]
    • addedInput schema / properties / run_id / description
      Added value: +"The run_id that start returned; needed for check and finish."
    • addedInput schema / properties / summary / description
      Added value: +"One-line summary, for finish."
  3. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

With annotations already declaring readOnlyHint=false and destructiveHint=false, the description goes well past them: it explains the gating rule (start returns go:false if a run is going or within 10 minutes of its planned end), how freeapply_clear_to_submit with run_id terminates a run, that finish releases the run and is harmless when repeated, the exact return shapes for each action, and the two error cases. This is the full behavioral burden discharged.

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?

Purpose and the sibling distinction are front-loaded, then labeled sections (Behavior, Parameters, Returns, Errors) keep the dense content navigable. It is long and information-dense — near the upper limit for a single tool description — but almost every clause is load-bearing given there is no output schema.

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?

A four-action tool with no output schema and cross-tool coupling to freeapply_clear_to_submit; the description covers returns for each action, the go:false reason categories, error conditions, and the call-site contract. Nothing needed to invoke it correctly is missing.

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 real meaning beyond the schema: run_id must be the value start returned, summary is "one line on the run" capped at 500 characters, and action is framed as the step selector whose effects vary per enum value. The 500-character limit and the required pairing of run_id with finish are details the schema does not carry.

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 pair and resource ("Starts and finishes unattended (scheduled) runs, and records the schedule") and explicitly distinguishes itself from freeapply_status by noting that status only shows run state while this changes it. An agent can tell which tool to pick without opening a 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?

Gives explicit when-to-use for each action (start at the beginning of every scheduled run, finish at its end including early stops, schedule_created/schedule_removed after creating or deleting the scheduled task) and an explicit exclusion ("Not in a session the user runs by hand"), plus the named alternative freeapply_status. Nothing is left to inference.

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