Skip to main content
Glama
FreeApply

FreeApply

Official
by FreeApply
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
JavaScript
Local

Check text and save the cover letter

freeapply_check_text
Idempotent

Verifies a cover letter or free-text answer against your profile and saved facts before you submit, flagging unsupported claims so you can fix them. Optionally saves a passing letter as a PDF.

Instructions

Checks a cover letter or free-text answer against what the user really has, and turns a passing cover letter into a PDF to upload. Unlike freeapply_update_job, which only records the result, it is where every piece of prose is checked before you type or attach it. Use it before typing any written answer or attaching any letter, and again after each fix. Not for short fields taken straight from the settings, such as a name, a date or yes/no. Behavior: flags every skill, tool, number or claim that the résumé, settings, highlights and saved answers don't support. Without save it changes nothing. With save a passing letter becomes a PDF in the documents folder, kept with the job; a failing one is never saved, saving again replaces the file, and a job already applied to is refused. Parameters: kind cover_letter also checks the user's chosen length, their sign-off, leftover placeholders and that the company is named; answer, the default, checks facts only. job_id adds the posting's keywords, counts numbers from the posting and the user's answers for that job as facts, and is needed for save. company names the employer when there is no job_id. For a letter, pass save from the first call so a passing letter is checked and saved at once. Returns: {ok, problems}, problems being plain sentences to fix, remove or ask the user about. With job_id also keywords {used, unused}: the posting's supported skills this text uses, and those it could still use. With save also file {path, name, bytes}, or a note why it wasn't saved. Errors: save without kind cover_letter and a job_id, or an unknown job_id. If the résumé was never saved, most claims are reported as unsupported.

Input Schema

NameRequiredDescriptionDefault
kindNoWhat the text is. Optional; default answer.
saveNoSave a passing cover letter as a PDF. Optional; default false.
textYesThe cover letter or answer to check, exactly as you will type or attach it.
job_idNoThe job it is for. Optional; needed for save.
companyNoThe employer, when there is no job_id. Optional.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.0.2
    • changedInput schema / properties / company / description
      Previous value: -"The employer it is addressed to. Optional; a cover letter that never mentions it is flagged."New value: +"The employer, when there is no job_id. Optional."
    • changedInput schema / properties / job_id / description
      Previous value: -"The job it is for. Optional; numbers from its posting and the user's answers for it then count as supported."New value: +"The job it is for. Optional; needed for save."
    • addedInput schema / properties / save
      Added value: +{
+  "description": "Save a passing cover letter as a PDF. Optional; default false.",
+  "type": "boolean"
+}
    • changedInput schema / properties / text / description
      Previous value: -"The cover letter or answer to check."New value: +"The cover letter or answer to check, exactly as you will type or attach it."
  2. Changed6 schema fields changedv1.0.1
    • addedInput schema / properties / company / description
      Added value: +"The employer it is addressed to. Optional; a cover letter that never mentions it is flagged."
    • addedInput schema / properties / job_id / description
      Added value: +"The job it is for. Optional; numbers from its posting and the user's answers for it then count as supported."
    • addedInput schema / properties / job_id / minimum
      Added value: +1
    • addedInput schema / properties / kind / description
      Added value: +"What the text is. Optional; default answer."
    • addedInput schema / properties / kind / enum
      Added value: +[
+  "cover_letter",
+  "answer"
+]
    • addedInput schema / properties / text / description
      Added value: +"The cover letter or answer to check."
  3. First observedv0.1.0

TDQS

A5/5.0
Behavior5/5

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

The description adds substantial behavior beyond the annotations: without save nothing changes, with save a passing letter becomes a PDF, a failing one is never saved, saving again replaces the file, and a job already applied to is refused. It also explains unsupported claims, error cases, and the résumé-unsaved edge case. This does not contradict the annotations; it enriches them.

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 long but front-loaded and structured as purpose, usage, behavior, parameters, returns, and errors. Every sentence contributes operational detail, including edge cases and return shapes, because no output schema exists. There is little redundancy despite the density.

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?

Given no output schema, the description supplies the return shape {ok, problems} and conditional keywords/file data. It covers save behavior, error conditions, prerequisite risks around an unsaved résumé, and parameter-specific checks. Nothing essential for correct invocation appears to be 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?

Although schema coverage is 100%, the description adds real meaning beyond the schema: kind cover_letter also checks length, sign-off, placeholders, and employer naming, while answer checks facts only. It explains that job_id adds posting keywords and is needed for save, and that company names the employer when job_id is absent. It also advises passing save from the first call for letters.

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 first sentence states a specific verb and resource: checking a cover letter or free-text answer and turning a passing cover letter into a PDF. It explicitly distinguishes itself from freeapply_update_job by saying that sibling only records the result, while this tool is where prose is checked. An agent can identify the tool without opening the 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?

It gives explicit timing: use before typing any written answer or attaching any letter, and again after each fix. It also states an exclusion: not for short fields taken straight from settings, such as name, date, or yes/no. The alternative freeapply_update_job is named and contrasted.

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