Coding agent documentation index Fetch the complete documentation index at: https://docs.worklittle.com/docs-agent-manifest.json Use this file to discover all available pages before exploring further.

Structured extraction

Use keywords and structured detail fields instead of raw description text. Covers why list rows are thin, what enrichment adds, and how to handle postings with no usable body.

get_job_keywords exists because feeding a full job description into a document model makes the output worse, not better.

Three tiers of job text

| Tier | Source | Contains | Good for |
| --- | --- | --- | --- |
| **List row** | `GET /jobs`, `search_jobs` | Title, company, location, flags, short summary | Ranking, display, filtering |
| **Detail** | `GET /jobs/:id`, `get_job_details` | Full responsibilities, qualifications, structured fields, salary hints | Explaining a role, answering questions about it |
| **Keywords** | `get_job_keywords` | Skills and technologies with prose stripped out | Resume and cover letter tailoring, skill overlap scoring |

Each tier is a deliberate reduction. Going up a tier costs a call. Going down a tier throws away noise. Pick the lowest tier that answers the question.

Why keywords beat the full description

A job description is mostly not about the job. It is company boilerplate, benefits copy, equal opportunity language, application instructions, and stylistic filler. When you paste all of that into a resume generation prompt, the signal you care about, the actual skill surface, is a small fraction of the tokens.

get_job_keywords returns that surface directly: skills and technologies, stripped of narrative. Use it as job_context on create_resume and create_cover_letter. The tool description says it plainly, and it is worth repeating: the extra words are confusing, and full descriptions degrade output quality.

The same reasoning applies to matching. Scoring a candidate against a keyword set is more stable than embedding a 900-word posting where half the vector is describing the company's culture.

Avoiding thin listings

Not every indexed posting arrives with substantive text. Some sources return titles and a one-line snippet until enrichment runs. Design for that.

Never present a list row summary as the description. It is a snippet by construction. Check before you reason. If get_job_details returns a body that is empty or near-empty, say the description is not available rather than inferring requirements from the title. Expect the first detail fetch to be slower. A one-time AI enrichment backfill may run on first read. Later reads are cached. API keys: first 100 AI generations/org/UTC day are free, then token rates; raw text and cached AI do not bill. Do not retry to force enrichment. Hammering the detail endpoint does not produce text that the source never published, and each call is billed. * Degrade honestly. A resume tailored to a title alone is a generic resume. Tell the user that instead of implying targeting you did not do.

On public boards the equivalent guarantee is stronger: description_sections plus description_sections_meta are designed never to hand you an empty unusable body.

Structured fields over parsing

When you need a fact, look for the field before you reach for a regex.

| Want | Field, not parsing |
| --- | --- |
| Can this be automated? | `can_apply` |
| Is this role still open? | `closed_at` |
| Where is it? | Geocoded location fields, not the title string |
| What does it pay? | Salary fields on detail, or `/jobs/salary-average` for a query |
| What does the form ask? | `application_fields` on the job detail |
| Can I autofill a resume? | `features.resume_autofill` |

Worklittle already ran enrichment for salary, location, experience level, and similar attributes. Re-deriving them from free text in your own code means you get a worse answer and it drifts from what filters actually match on.

Pitfalls

| Pitfall | What to do instead |
| --- | --- |
| Full description into a document prompt | `get_job_keywords` into `job_context` |
| Treating list snippets as complete | Fetch detail before summarizing requirements |
| Regex on the title for seniority | Use `seniority_level` as a filter |
| Inventing requirements when the body is thin | Say the description is not available |
| Fetching keywords for roles the user rejected | Extract only after shortlisting |

Related docs

Search jobs, Create resumes, Grounding, Tool chains.