Skip to main content
Glama

cv.json — open CV data

by io.github.freecvorg

search_open_to_work

Search FreeCV's LIVE index of real people who are open to work — by skills, role/title, location, and recruiter facets (work type, employment type, visa sponsorship, languages, minimum experience). Returns lean candidate cards (name, current role @ company, location, top skills, languages, and the full availability preferences) plus each person's cv.json URL and portfolio URL — enough to shortlist WITHOUT a fetch_cv per candidate. Call fetch_cv on a result to read the complete structured CV. Only already-public profiles are indexed; contact details are never returned (reach candidates via their portfolio).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNoRanking: best match (default), most recently updated, or most experienced.
limitNoMax results per page (default 20).
queryNoFree-text query matched across name, title, skills and experience (e.g. "senior react developer").
titleNoTarget role/title, e.g. "Product Designer".
offsetNoResult offset for paging through a large shortlist (default 0). Use with `total` in the response.
skillsNoSpecific skills to match, e.g. ["React","TypeScript"].
locationNoCountry-aware location filter, e.g. "UK" (matches London/Manchester), "Berlin", "Gaza".
workTypeNoOnly candidates who OFFER one of these work arrangements.
languagesNoLanguages the candidate must speak, e.g. ["German","Arabic"].
minYearsExpNoMinimum years of experience.
sponsorshipNoFilter by visa-sponsorship need: false = does NOT need sponsorship, true = needs it. Candidates who never answered are excluded from this filter.
employmentTypeNoOnly candidates open to one of these employment types.

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so well. It discloses the privacy/access boundary ('contact details are never returned (reach candidates via their portfolio)'), the source scope ('only already-public profiles are indexed'), and the output intent ('lean candidate cards'). It also reveals behavioral context like 'LIVE index' to signal freshness.

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?

Two dense sentences cover the purpose, filter dimensions, output shape, workflow with fetch_cv, and privacy caveat. The most important distinction—shortlist without fetch_cv—is front-loaded, and no sentence is 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 12-parameter search tool with no output schema and no annotations, this description is notably complete. It tells the agent what cards contain, includes URLs returned, explains how to use the result with fetch_cv, and discloses the key limitations. Sorting and pagination are already documented in the schema, so nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already explains every parameter and enum. The description summarizes filter categories ('skills, role/title, location, and recruiter facets') but adds no parameter-level detail beyond what the schema provides. Baseline 3 is appropriate.

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 names a specific verb ('Search') and a distinct resource ('FreeCV's LIVE index of real people who are open to work'), then specifies what it returns and how it differs from fetch_cv. It clearly distinguishes this tool from the sibling tools by stating it is enough to shortlist without calling fetch_cv.

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?

Usage guidance is explicit: search here to shortlist, then 'Call fetch_cv on a result to read the complete structured CV.' It also clarifies the boundary that only public profiles are indexed and contact details are never returned, so an agent knows when this tool is relevant and when to follow up with fetch_cv.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All cv.json — open CV data toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: fetching a CV, retrieving the schema, searching the open-to-work index, and validating a document. Even where fetch_cv and validate_cv both accept a slug/url, their outputs are completely different and unambiguous.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: fetch_cv, get_cvjson_schema, search_open_to_work, validate_cv. The verbs are descriptive and the naming style is uniform across the set.

Tool Count5/5

Four tools is well-scoped for a read-only CV data server: retrieve, search, validate, and schema access. Each tool earns its place and there is no unnecessary redundancy.

Completeness5/5

The tool surface covers the core lifecycle for the domain: searching for candidates, fetching full CVs, understanding the schema, and validating documents. The integration between search results and fetch_cv via URLs creates a complete workflow with no obvious dead ends.

Resources