Skip to main content
Glama
FreeApply

FreeApply

Official
by FreeApply
OverviewSchemaSourceRelated ServersDiscussions(2)Admin
JavaScript
Local

Check FreeApply and get a procedure

freeapply_get_status
Read-onlyIdempotent

Check whether FreeApply can run now and get the signed step-by-step procedure for a task, so you can confirm Terms, setup, and readiness before starting work.

Instructions

Whether FreeApply can work now, plus the signed step-by-step procedure for a task. About FreeApply itself (user details: freeapply_get_settings; job search: freeapply_get_stats). Use: first in every session and before each task; with wait after asking the user to accept the Terms or finish setup in the dashboard. Works while locked or the Terms are unaccepted, so it can say why. Behavior: read-only: reports what FreeApply set up when it started (data folder, database, dashboard, the résumé copy to upload). wait holds the call up to 10 minutes until the Terms are accepted and setup is complete, and returns within seconds of that. Parameters: none for status only; procedure adds that task's signed steps; lane (with procedure freeapply-apply) is for a helper: only the hard rules and that lane's steps, with a short status; wait as above, with or without procedure. Returns: workflow {ok, problem}, terms {ok}, setup_complete, missing, sites [{id, name, ready}] (chosen job sites), autorun, update, dashboard (URL), data_dir, documents {dir, resume, cover_letters}, stats, procedures, models {can_delegate, rescan, levels, lanes, unfilled} (each level and lane {model, effort, source}; model current = your own model does it). With procedure also procedure {name, description, text, workflow_version, workflow_hash}, null while locked. wait_again true: a wait ran out first; call again. Next: workflow.ok false: tell the user why, stop. terms.ok or setup_complete false: follow freeapply-setup. models.rescan true: do its AI models step first.

Input Schema

NameRequiredDescriptionDefault
laneNoA helper's lane of freeapply-apply; the agent that starts helpers omits it.
waitNoHold the call until the Terms are accepted and setup is complete (up to 10 minutes).
procedureNofreeapply-setup (first run; Terms or settings missing; starting auto-run), freeapply-apply (find jobs, apply) or freeapply-replies (email reply check).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.6

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/destructive=false, but the description adds substantial non-obvious behavior: wait can hold up to 10 minutes until Terms are accepted, returns within seconds of completion, and it discloses what setup state is reported. It also explains wait_again semantics for a timed-out wait.

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?

Structure is excellent — purpose, use, behavior, parameters, returns, and next steps are clearly separated and front-loaded. It is dense and the Returns enumeration is long, but almost every clause carries actionable information for a complex tool; minor verbosity only.

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?

No output schema exists, so the description must explain returns — and it does thoroughly, enumerating the workflow, terms, setup, sites, documents, and procedure fields. It also provides failure-branch guidance (workflow.ok false → stop; terms/setup false → freeapply-setup; rescan → models step), making it complete for a tool of this complexity.

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 the baseline is 3, but the description materially adds meaning: 'lane (with procedure freeapply-apply) is for a helper: only the hard rules and that lane's steps,' which explains an interaction constraint the schema does not. It doesn't fully enumerate each param's individual effect, but the added interaction semantics push it above baseline.

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?

The opening line states a specific dual purpose: reporting whether FreeApply can work now and returning a signed step-by-step procedure. It also explicitly disambiguates from siblings by naming freeapply_get_settings (user details) and freeapply_get_stats (job search), so an agent can route without opening schemas.

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?

Usage is prescriptive: 'first in every session and before each task,' and use the wait flag after asking the user to accept Terms or finish setup. It even notes it works while locked/unaccepted, so its purpose as a diagnostic tool is unambiguous.

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