Skip to main content
Glama
FreeApply

FreeApply

Official
by FreeApply
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
JavaScript
Local

Fetch a job posting

freeapply_fetch_posting
Read-onlyIdempotent

Fetches a single job posting from its URL and returns trimmed description, form questions, suggested answers, and required skills for scoring or applying without browser overhead.

Instructions

Fetches one job posting on the user's computer and returns it trimmed, with its form questions, suggested answers and the skills it asks for. Unlike opening the page in the browser it costs few tokens; you still use the browser to fill in and submit the form. Use it to read each posting before scoring or applying. Not for search-results pages or pages behind a sign-in; read those in the browser. Behavior: read-only; one web request from the user's computer. Greenhouse, Lever and Ashby postings are read through their public APIs, other sites as plain page text. Only public http and https pages are fetched: an address on this computer or a local network, or a redirect to one, is refused. The posting is remembered for this session, so freeapply_claim_job can keep its keywords. Parameters: url is the job page or its application form. max_chars caps the description (default 6000, at least 500); description_chars gives its full length. source, a job site id such as linkedin, picks the saved answers meant for that site. Returns: ats, title, company, location, work_mode, pay, description, description_chars, questions (label, required, type, options), suggested_answers (from settings and saved answers; answer anything else only from the résumé or the user) and keywords {matched, missing, coverage}: use matched skills in the posting's words, never claim missing ones; coverage is the matched share in percent, null when the posting names none. Errors: a bad or local address, or a page that can't be fetched, with the reason; then read it in the browser. Next: freeapply_claim_job.

Input Schema

NameRequiredDescriptionDefault
urlYesThe posting's URL: the job page or its application form.
sourceNoThe job site id where it was found. Optional.
max_charsNoLongest description to return, in characters. Optional; default 6000.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.2
    • changedInput schema / properties / source / description
      Previous value: -"Where the posting was found, as a job site id (linkedin, indeed, company_sites, ...). Optional; helps pick suggested answers."New value: +"The job site id where it was found. Optional."
  2. Changed5 schema fields changedv1.0.1
    • addedInput schema / properties / max_chars / default
      Added value: +6000
    • addedInput schema / properties / max_chars / description
      Added value: +"Longest description to return, in characters. Optional; default 6000."
    • addedInput schema / properties / max_chars / minimum
      Added value: +500
    • addedInput schema / properties / source / description
      Added value: +"Where the posting was found, as a job site id (linkedin, indeed, company_sites, ...). Optional; helps pick suggested answers."
    • addedInput schema / properties / url / description
      Added value: +"The posting's URL: the job page or its application form."
  3. First observedv0.1.0

TDQS

A4.6/5.0
Behavior4/5

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

Goes well beyond annotations by disclosing per-site API vs page-text behavior, the SSRF-style refusal of local/private addresses and redirects, and session-level caching that freeapply_claim_job depends on. Annotations already cover read-only/idempotent, so this adds real operational context; error handling is summarized but retry semantics for transient failures are not spelled out.

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 purpose, then usage, behavior, parameters, returns, errors, and next step — a clean, scannable structure. Slightly dense in the params/returns sentences, but nearly every clause carries information an agent needs.

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?

Even without an output schema, the description enumerates the returned fields including the keywords {matched, missing, coverage} triple and the guidance not to claim missing skills. Errors and the follow-up tool are covered, so an agent can invoke and act on the result without guessing.

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; the description adds meaning the schema lacks, such as max_chars capping only the description, description_chars reporting full length, and source selecting site-specific saved answers. That is genuine value beyond the schema text.

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 ('Fetches one job posting') and immediately scopes it: trimmed, with form questions, suggested answers, and required skills. It explicitly contrasts with the browser alternative and with search-results pages, so an agent can distinguish it from siblings like freeapply_list_jobs.

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?

Explicit when-to-use ('read each posting before scoring or applying') and when-not ('not for search-results pages or pages behind a sign-in; read those in the browser'). It also names the next tool in the workflow (freeapply_claim_job), giving a complete routing decision.

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