Skip to main content
Glama
FreeApply

FreeApply

Official
by FreeApply
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
JavaScript
Local

Save settings and résumé

freeapply_update_settings
DestructiveIdempotent

Save user-provided facts, preferences, résumé setup details, and AI model scan results into FreeApply settings; only sent fields change, so you can update specific settings safely.

Instructions

Saves what the user told you, what setup reads from their résumé, and the AI models scan. Unlike freeapply_user_answers, which keeps answers to single form questions, it changes the settings themselves. Use it when the user states a fact or preference, in setup to store the résumé's text and profile, and in the AI models step. Don't fill a field the user didn't give you; to read settings, use freeapply_get_settings. Behavior: overwrites the fields you send, with no undo. patch is deep-merged: only its fields change, nested objects merge, lists are replaced whole. Sections only the user changes in the dashboard (legal, sharing, automation, autorun, onboarding, integrity, model_choices) are skipped and listed in ignored. All or nothing: if any field is wrong, nothing is saved. Parameters: patch is nested by section with freeapply_get_settings' field names, e.g. {"targets": {"min_pay": 60000}}. resume takes only text and profile ({headline, skills, titles, education, certifications}, from the résumé text alone). models is the scan {app, current, can_delegate, available, efforts}, read from your own tools; it replaces the last scan. Returns: {changed, ignored, setup_complete, missing}; after a scan also models, the model and effort chosen for each level. Errors: nothing writable, an unknown section or field, a wrong type, a value outside its choices (e.g. cover_letter.length is short, standard or long), résumé files (the user adds those in the dashboard) or a malformed scan. The message names every problem.

Input Schema

NameRequiredDescriptionDefault
patchYesThe fields to change, nested by section, e.g. {"profile": {"phone": "+1 555 0100"}}.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.2
    • changedInput schema / properties / patch / description
      Previous value: -"The fields to change, nested by section, e.g. {\"targets\": {\"min_pay\": 60000, \"locations\": [\"Denver, CO\"]}} or {\"profile\": {\"phone\": \"+1 555 0100\"}}. Field names are as freeapply_get_settings returns them."New value: +"The fields to change, nested by section, e.g. {\"profile\": {\"phone\": \"+1 555 0100\"}}."
  2. Changed1 schema field changedv1.0.1
    • addedInput schema / properties / patch / description
      Added value: +"The fields to change, nested by section, e.g. {\"targets\": {\"min_pay\": 60000, \"locations\": [\"Denver, CO\"]}} or {\"profile\": {\"phone\": \"+1 555 0100\"}}. Field names are as freeapply_get_settings returns them."
  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 annotations already mark the tool as destructive and non-read-only, but the description adds crucial behavior: fields are overwritten with no undo, patch is deep-merged, lists are replaced wholesale, dashboard-only sections are skipped and returned in ignored, and the operation is all-or-nothing. It also describes return fields and error cases, giving the agent a full operational picture beyond annotations.

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?

Despite its length, the description is front-loaded with purpose, then usage, behavior, parameter details, returns, and errors. Each section carries distinct, necessary information for a complex write operation, and no sentence is redundant filler.

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?

For a complex mutation tool with no output schema, the description covers when to use it, how merging and skipping work, all-or-nothing behavior, return shape, and error conditions. It gives the agent everything needed to invoke the tool correctly and interpret its results.

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 100%, but the description still adds substantial meaning: patch is nested by section using freeapply_get_settings field names, with a concrete example. It further explains resume's text/profile shape and models' scan shape, including that models replaces the last scan. This goes well beyond the schema's generic patch description.

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 description uses specific verbs and resources: saving settings, résumé setup data, and AI model scan data. It explicitly distinguishes itself from freeapply_user_answers by saying it changes settings themselves rather than single-question answers. An agent can identify the tool's purpose and boundary against siblings 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?

It gives explicit usage conditions: when the user states a fact or preference, during setup to store résumé text/profile, and in the AI models step. It also gives exclusions and alternatives: do not fill fields the user did not provide, and use freeapply_get_settings to read settings. This is clear when-to-use and when-not-to-use guidance.

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