Skip to main content
Glama
FreeApply

FreeApply

Official
by FreeApply
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
JavaScript
Local

Read the user's settings

freeapply_get_settings
Read-onlyIdempotent

Reads the user's stored profile, job targets, eligibility, and résumé so agents can score jobs or fill forms without inventing facts; also reports missing required fields.

Instructions

Reads the user's settings: who they are, what they're looking for and how FreeApply should work. Unlike freeapply_user_answers (answers to single form questions) and freeapply_status (whether FreeApply can run), it holds the facts about the user. Use it once per session, or once per helper, before scoring jobs or filling in a form. With the résumé text and the user's own words it is the only source of facts about the user: never invent what it doesn't contain. To change settings, use freeapply_update_settings. Behavior: read-only; installation secrets are never included. Parameters: sections limits the reply to what a step needs, e.g. ["profile", "eligibility"] for a form; leave out resume, the largest, when you don't need its text. Default all. Returns: {settings, missing}. Sections: profile, targets, eligibility, resume (file paths, text, profile), cover_letter, automation, autorun, gmail, custom_answers, models, model_choices and sharing (choices only). missing lists required fields still empty as {key, label}; while it isn't empty, don't apply anywhere: open the settings tab with freeapply_open_dashboard and ask the user to fill them. Errors: an unknown section name; the message lists the valid ones.

Input Schema

NameRequiredDescriptionDefault
sectionsNoSections to return. Optional; default all.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.2
    • addedInput schema / properties / sections
      Added value: +{
+  "description": "Sections to return. Optional; default all.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  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?

Annotations already cover read-only/idempotent/non-destructive, yet the description still adds value beyond them: installation secrets are never included, the return shape is {settings, missing}, and `missing` acts as a blocking precondition. It also discloses the error case (unknown section name, message lists valid ones) and a guardrail against fabricating user facts.

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?

Front-loaded with purpose, then labeled Behavior/Parameters/Returns/Errors, and nearly every sentence carries actionable content. It is, however, a dense paragraph with deeply nested parentheticals (the long section enumeration) that would scan faster as a list; slight tightening is possible without losing information.

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?

With no output schema and only one optional parameter, the description compensates fully: it enumerates the returned sections and their contents, explains `missing`, describes the error path, and states the session-level calling convention. Nothing an agent needs to invoke or interpret the result 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 100%, so baseline would be 3, but the description adds real meaning: `sections` narrows the reply to what a step needs, is illustrated with a concrete example (["profile", "eligibility"] for a form), defaults to all, and warns that resume is the largest and should be omitted when its text isn't needed — a cost hint the schema lacks.

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?

Opens with a specific verb+resource ("Reads the user's settings") and immediately scopes it: identity, targets, and FreeApply behavior. It explicitly names the two nearest siblings (freeapply_user_answers and freeapply_status) and states how this differs from each, so an agent can select 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 concrete when-to-use ("once per session, or once per helper, before scoring jobs or filling in a form") plus the exclusion and alternative ("To change settings, use freeapply_update_settings"). It also adds a gated follow-up path: while `missing` is non-empty, open the dashboard and ask the user, rather than proceeding.

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