Skip to main content
Glama
FreeApply

FreeApply

Official
by FreeApply
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
JavaScript
Local

Check FreeApply and get a procedure

freeapply_status
Read-onlyIdempotent

Checks whether FreeApply can run now and returns the signed step-by-step procedure for setup, applying, or reply checks; run it first each session and before tasks.

Instructions

Reports whether FreeApply can work now and returns the signed step-by-step procedure for a task. Unlike freeapply_get_settings (the user's details) and freeapply_job_stats (the job search), it is about FreeApply itself. Use it first in every session and before each task; call it again only to re-check after the user acts. It works while FreeApply is locked or the Terms aren't accepted, so it can tell you why. Behavior: changes no user data. Sets up the data folder on first run, starts the local dashboard if needed and refreshes the résumé copy in the documents folder. Parameters: procedure adds that task's text: freeapply-setup (first run, or Terms or settings missing), freeapply-apply (find jobs and apply) or freeapply-replies (Gmail reply check). Omit it for the status alone. Returns: workflow {ok, problem}, terms {ok}, setup_complete, missing, sites (each chosen job site with ready), autorun, update, dashboard (its URL), data_dir, documents {dir, resume, cover_letters}, stats, procedures, and models {can_delegate, rescan, levels, lanes, unfilled}: each level and lane gives {model, effort, source}, and model current means your own model does it. With procedure also procedure {name, description, text, workflow_version, workflow_hash}, null while locked. Next: workflow.ok false: tell the user why and stop. terms.ok or setup_complete false: follow freeapply-setup. models.rescan true: do its AI models step first.

Input Schema

NameRequiredDescriptionDefault
procedureNoThe task whose procedure to include. Optional.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.2
    • addedInput schema / properties / procedure
      Added value: +{
+  "description": "The task whose procedure to include. Optional.",
+  "enum": [
+    "freeapply-setup",
+    "freeapply-apply",
+    "freeapply-replies"
+  ],
+  "type": "string"
+}
  2. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the readOnly/idempotent/non-destructive annotations by disclosing side effects an agent would otherwise not expect: creating the data folder on first run, starting the local dashboard, and refreshing the résumé copy. It also documents the failure semantics (works while locked, reports why) rather than hiding them. Only mild tension exists between readOnlyHint and those setup side effects, but the description surfaces them openly rather than concealing them.

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?

Well front-loaded — purpose first, then sibling contrast, then usage, then Behavior/Parameters/Returns/Next sections, making it easy to scan. It is on the long side, though: the full enumeration of models {can_delegate, rescan, levels, lanes, unfilled} and per-lane {model, effort, source} is heavier detail than most invocations need.

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?

There is no output schema, and the description compensates by enumerating the returned fields, calling out the conditional procedure payload and its null-while-locked behavior, and giving error-handling next steps. For a status-plus-procedure gate tool with 17 siblings, nothing an agent needs in order to call it correctly is missing.

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?

Schema coverage is already 100% with an enum, yet the description adds selection logic the enum values alone do not convey: freeapply-setup for first run or missing Terms/settings, freeapply-apply for finding and applying to jobs, freeapply-replies for the Gmail reply check, and 'omit it for the status alone'. This is real added meaning over the schema.

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 ('Reports whether FreeApply can work now and returns the signed step-by-step procedure for a task') and explicitly distinguishes itself from the two nearest siblings: freeapply_get_settings (user details) and freeapply_job_stats (job search). An agent can route to it without opening any 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 timing rules ('Use it first in every session and before each task; call it again only to re-check after the user acts'), an edge-case guarantee (works while locked or Terms not accepted), and concrete branching in 'Next' for workflow.ok false and terms.ok/setup_complete false. Both when-to-use and what-to-do-next are spelled out.

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