Server data from the Official MCP Registry
Search people open to work and fetch their machine-readable cv.json, from any AI assistant.
About
Search people open to work and fetch their machine-readable cv.json, from any AI assistant.
Remote endpoints: streamable-http: https://freecv.org/api/mcp
Security Report
Valid MCP server (1 strong, 0 medium validity signals). No known CVEs in dependencies. ⚠️ Package registry links to a different repository than scanned source. Imported from the Official MCP Registry. 2 finding(s) downgraded by scanner intelligence.
4 tools verified · Open access · 2 issues found
Security scores are indicators to help you make informed decisions, not guarantees. Always review permissions before connecting any MCP server.
Permissions Required
This plugin requests these system permissions. Most are normal for its category.
How to Install & Connect
Available as Local & Remote
This plugin can run on your machine or connect to a hosted endpoint. during install.
Documentation
View on GitHubFrom the project's GitHub README.
cv.json
An open schema for publishing a CV as a single JSON document at a stable URL — so AI agents, ATS systems, and other tools can read career data without parsing a PDF.
Site · Validator · Schema (v1) · /.well-known/cv.json (discovery)
Status
Emerging. cv.json is not a ratified standard. It is a small, opinionated schema currently maintained by FreeCV and used in production on the FreeCV portfolio platform. We're publishing the schema, validator, and examples here so other tools can adopt it and so the schema can evolve in the open. If you ship a CV product and want a say in v2, open an issue.
cv.json keeps the top-level field names of basics, work, education, skills, projects, languages, publications, awards, volunteer, interests, references, and meta familiar — anyone who has touched a JSON-shaped CV before should feel at home. It adds fields the rest of the ecosystem doesn't have (availability, ats, verification, referencesMode, i18n, the v1.3 hiring-signal block, and x-customSections for user-defined sections) and pins down date formats and a discovery convention.
60-second demo
Every published cv.json lives at a stable URL. No auth, no API key, plain HTTP. Try it right now — the demo profile is live (Ashley is fictional; the endpoint and format are real):
$ curl -s https://livelink.cv/ashley/cv.json | jq '.basics.name, .work[0].company'
"Ashley Carter"
"Brightfold Studio"
The response advertises its schema in headers:
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
X-CV-Version: 1.2.2
Link: <https://cvjson.com/schema/v1.json>; rel="describedby"
Access-Control-Allow-Origin: *
Cache-Control: public, max-age=300
Sites that host a CV can also declare it in HTML for crawlers:
<link rel="alternate" type="application/json"
href="/ashley/cv.json" title="cv.json" />
…or expose a site-wide discovery manifest at /.well-known/cv.json listing all CVs hosted on the domain.
Schema at a glance
Only basics and meta are required. Everything else is optional and consumers MUST ignore unknown fields.
| Section | Type | Purpose |
|---|---|---|
basics | object | Name, label, image, summary, location, contact, social profiles |
work | array | Roles: company, position, dates, summary, highlights, per-role url |
education | array | Institution, degree, area, dates, score, summary, highlights, url |
projects | array | Name, role, description, URL, keywords, highlights |
skills | array of strings | Flat list of skill names |
languages | array | Language + fluency level |
certificates | array | Name, issuer, date, verification URL |
publications | array | Papers, articles, books |
awards | array | Honors and recognitions |
volunteer | array | Volunteer roles, same shape as work |
interests | array of strings | Flat list of interests |
references | array | Name, title, company, relationship, email, phone |
referencesMode | enum | "show" | "on-request" | "hide" (default "hide") |
availability | object | Job-seeking status, preferred roles, work type, sponsorship |
ats | object | Auto-generated keywords, years of experience, seniority — hints, not authoritative |
verification | object | Trust signals: email verified, source platform |
i18n | object | Primary language + map of translated cv.json URLs |
meta | object | version, canonical, lastModified, generator |
x-customSections | array | Vendor extension (v1.2.1). User-defined sections with no standard home — e.g. "Speaking", "Patents". Shaped [{ name, items: [{ name, summary?, highlights?, date?, endDate?, url? }] }]. Standard-named sections fold into their canonical arrays instead; consumers ignore unknown x- fields. |
x-personal | object | Vendor extension (v1.2.2). Opt-in regional personal fields: dateOfBirth, gender, nationality, placeOfBirth, maritalStatus. Expected in much of Europe / MENA / Asia, discouraged in the US/UK/CA/AU. Sensitive PII — publishers SHOULD gate these on public endpoints behind the user's consent; consumers ignore unknown x- fields. |
Date fields accept YYYY, YYYY-MM, or YYYY-MM-DD. The full schema is at schema/v1.json.
Why cv.json exists
Three problems, one schema.
1. PDFs are unparseable in practice. Every CV in the world eventually meets an ATS. ATS parsers are notorious for merging job titles into dates, putting names in the address field, and silently dropping skills. The fix isn't a better parser — it's not parsing in the first place.
2. Existing JSON CV schemas have stalled. The shape of a JSON résumé has been a solved problem for years, but nothing in the space has moved meaningfully — no discovery convention, no version negotiation, no availability or ATS signals, no references-mode. cv.json picks up the parts that haven't been touched and ships them under a real versioning policy.
3. AI agents need structured career data. Recruiting agents, candidate-search tools, and matching systems are being built right now against scraped PDFs and HTML. A canonical JSON endpoint at a known URL is the cheapest way to feed them — same role HTML played for browsers, robots.txt played for crawlers, OpenAPI plays for APIs.
cv.json is the file. The URL is the contract.
Quick start
Option 1 — Publish via FreeCV (easiest)
- Sign up at freecv.org, build your CV in the editor.
- Enable the public endpoint in Dashboard → Settings → Public cv.json.
- Your endpoint goes live at
https://livelink.cv/{your-slug}/cv.json.
That's the whole thing. Update your CV once, every consumer fetching the URL gets the new version.
Option 2 — Self-host
You don't need FreeCV. Any web server can serve a cv.json. Minimal recipe:
- Write a JSON file conforming to
schema/v1.json. Start fromexamples/minimal.json. - Serve it at a stable URL with
Content-Type: application/jsonand (ideally)Access-Control-Allow-Origin: *. - Add a discovery
<link>to the HTML page that "represents" you (portfolio, personal site). - Validate before publishing:
npx -y ajv-cli validate \
-s https://cvjson.com/schema/v1.json \
-d my-cv.json
Or paste it into freecv.org/validate.
Recommended response headers
Content-Type: application/json; charset=utf-8
X-CV-Version: 1.2.2
Link: <https://cvjson.com/schema/v1.json>; rel="describedby"
Access-Control-Allow-Origin: *
Cache-Control: public, max-age=300
X-CV-Version lets consumers branch behavior without parsing the body. Access-Control-Allow-Origin: * is what makes the file usable from browser tools — please set it.
Minimal example
{
"$schema": "https://cvjson.com/schema/v1.json",
"basics": {
"name": "Jane Smith",
"label": "Software Engineer",
"location": "London, UK",
"summary": "Full-stack developer with 3 years building web apps."
},
"work": [{
"company": "Acme Corp",
"position": "Software Engineer",
"startDate": "2022-03",
"current": true,
"highlights": ["Cut deploy time by 40% with new CI pipeline"]
}],
"skills": ["TypeScript", "React", "Node.js", "PostgreSQL"],
"education": [{
"institution": "University of London",
"degree": "BSc Computer Science",
"endDate": "2022"
}],
"meta": {
"version": "1.2.2",
"canonical": "https://example.com/cv.json",
"lastModified": "2026-06-01",
"generator": "hand-written"
}
}
See examples/ for a fuller document, a references-mode demo, and edge cases.
Discovery
Two complementary mechanisms:
Per-page link. On any HTML page that represents a person, add:
<link rel="alternate" type="application/json"
href="/cv.json" title="cv.json" />
This is the same pattern RSS used. Crawlers and agents can find a person's CV from any page they're mentioned on.
Site-wide manifest. A platform hosting many CVs (job board, agency, talent network) can publish a discovery manifest at /.well-known/cv.json:
{
"standard": "cv.json",
"version": "1.2.2",
"schema": "https://cvjson.com/schema/v1.json",
"endpointPattern": "https://example.com/{slug}/cv.json",
"discovery": {
"humanReadable": "https://example.com/{slug}",
"machineReadable": "https://example.com/{slug}/cv.json",
"index": "https://example.com/sitemap-portfolios.xml"
}
}
The manifest tells a machine how CVs on the domain are addressed and where the index of live endpoints lives (a sitemap or an inline endpoints array — either is conformant). One HTTP request, and an agent knows how to enumerate every CV the site is willing to expose. FreeCV serves this at https://freecv.org/.well-known/cv.json, with the quality-gated index at livelink.cv/sitemap-portfolios.xml.
Adopters
If you publish or consume cv.json, add yourself here via PR.
Publishers
| Platform | Endpoint pattern | Notes |
|---|---|---|
| FreeCV | https://livelink.cv/{slug}/cv.json | The FreeCV builder publishes every portfolio here. Free, production, schema v1.2.2 |
| your tool here |
Consumers
| Tool | What it does |
|---|---|
| cvjson.com/validator | Web validator against the published schema |
| your tool here |
PRs welcome. Be honest about implementation status (production, beta, prototype).
Versioning policy
cv.json follows semver at the schema level.
| Version | Status | What changes |
|---|---|---|
v1.0 | Stable (frozen) | Original release. Documents remain valid forever. |
v1.1 | Stable | Date validation, publications, awards, interests, projects.role/highlights, education.summary, volunteer.summary, employment types, ats clarified. |
v1.2 | Current stable (latest patch v1.2.2) | references, referencesMode. v1.2.1: documents x-customSections + root additionalProperties. v1.2.2: work[].url, education[].url, x-personal. |
v1.3-preview | Preview | Hiring-side signal block — see stability tiers below. Schema published as schema/v1.3-preview.json. |
v2.0 | Future | Reserved for breaking changes. No timeline. |
Rules within v1.x:
- New fields are additive and optional. Consumers MUST ignore unknown fields.
- No field is renamed or removed within v1.x — even when we know the name isn't great. (For example,
basics.labelvs the more obviousbasics.jobTitlestays as-is for JSON Resume interop; it changes in v2.) - Validation rules only get stricter within a minor bump if it's a clarification, never a real tightening that invalidates documents in the wild.
Declaring the version. Producers should set meta.version to the highest minor version whose fields they use, and serve X-CV-Version matching. Consumers should branch on X-CV-Version for cheap version checks.
v1.3 stability tiers
v1.3 adds a sizeable hiring-signal block on top of stable v1.2. To stay honest about which of those fields are usable today vs. which depend on platform work that hasn't shipped yet, every v1.3 field falls into one of three tiers:
Tier 1 — Ready today. Fields a producer can fill in by hand and an ATS or agent can act on immediately. No platform infrastructure required. These are: compensation, workAuthorization, locationPreferences, intentions, outreachControls, highlights, provenance, x-customSections.
x-customSections is the standard's one vendor extension (documented in stable v1.2.1 and carried forward in v1.3): an x--prefixed array for user-defined sections that have no standard home (e.g. "Speaking Engagements", "Patents"), shaped [{ name, items: [{ name, summary?, highlights?, date?, endDate?, url? }] }]. Producers fold standard-named sections (Awards, Volunteering, Publications, Interests) into their canonical arrays instead, so only genuinely novel sections land here. The x- prefix follows the JSON Schema vendor-annotation convention, so consumers that don't understand it ignore it and the document stays valid. Already emitted in production by FreeCV — and as of v1.2.1 it is documented in the stable v1 schema, not just this preview.
Tier 2 — Needs platform. Fields whose shape is stable, but whose value is only useful if a publisher (FreeCV or another) auto-populates and refreshes them. Hand-written values go stale fast. These are: signals (GitHub, speaking, writing), researchSignals (Google Scholar, OpenReview, ORCID), credentials (W3C Verifiable Credentials).
Tier 3 — Future-looking. Fields whose semantics are real but whose enforcement depends on consumer behavior — they only matter if recruiters, ATSs, and agents honor them. These are: privacy (audience-scoped visibility), policy (consumer obligations).
If you're publishing a CV by hand, fill in Tier 1 fields where they apply, skip Tier 2 unless you genuinely keep the numbers fresh, and treat Tier 3 fields as a signal of intent rather than a guarantee. The full schema accepts all three tiers — the tiering is editorial guidance, not a validation rule.
Repository layout
schema/
v1.json JSON Schema (draft-07) for stable v1.x (v1.0–v1.2.2)
v1.3-preview.json JSON Schema for the v1.3 preview, additive over v1.json
examples/
minimal.json Smallest valid document — basics + meta only
typical.json What most people publish — work, education, skills, languages
full-v1.2.json Every section of stable v1.2 populated
full-v1.3.json Every section of v1.3 populated, including all tier-1 hiring signals
academic.json Researcher CV: publications, awards, researchSignals, degree credentials
with-references.json Demonstrates referencesMode
with-privacy.json Demonstrates privacy.excludeAudience (block current employer)
with-credentials.json Demonstrates W3C VerifiableCredential pattern across roles
validate.js CLI validator (node validate.js path/to/cv.json)
CONTRIBUTING.md How to propose changes
LICENSE MIT
Badge
If you publish a cv.json, drop this badge in your README or portfolio so it's visible:
[](https://cvjson.com)
The badge links to the standard's home. The badge SVG is served from cvjson.com/badge.svg and is free to embed.
License
- Schema (this repository, including
schema/v1.json, examples, validator, docs): MIT. Fork it, embed it, ship it. - "cv.json" as a name: trademark of FreeCV, licensed for free use by any implementation that conforms to the published schema. We're not going to chase anyone — the only thing we'll push back on is a fork that diverges from the schema while still calling itself "cv.json." Call your fork something else and we're good.
Links
- Standard home — https://cvjson.com
- JSON Schema (v1) — https://cvjson.com/schema/v1.json
- Validator — https://cvjson.com/validator
- Live demo endpoint — https://livelink.cv/ashley/cv.json (fictional profile, real format)
- Discovery manifest — https://freecv.org/.well-known/cv.json
- Builder (reference implementation) — https://freecv.org/builder
- Issues / proposals — https://github.com/freecvorg/cv-json/issues
- Background post — https://freecv.org/blog/cv-json
Reviews
No reviews yet
Be the first to review this server!
More Developer Tools MCP Servers
Git
Freeby Modelcontextprotocol · Developer Tools
Read, search, and manipulate Git repositories programmatically
Fetch
Freeby Modelcontextprotocol · Developer Tools
Web content fetching and conversion for efficient LLM usage
Toleno
Freeby Toleno · Developer Tools
Toleno Network MCP Server — Manage your Toleno mining account with Claude AI using natural language.
mcp-creator-python
Freeby mcp-marketplace · Developer Tools
Create, build, and publish Python MCP servers to PyPI — conversationally.
MCP Marketplace
Freeby mcp-marketplace · Developer Tools
Search and install MCP servers from inside your AI client.
MarkItDown
Freeby Microsoft · Content & Media
Convert files (PDF, Word, Excel, images, audio) to Markdown for LLM consumption
