Civify MCP Server lets AI agents interact with the Civify career platform to handle authentication, resume AI, job insights, monetization, and application tracking.
Authenticate and manage accounts: log in, register, set API keys, verify 2FA, log out, and view account/profile/credits.
Parse resumes: extract structured JSON (contact, experience, education, skills, projects) from PDF/DOCX/image.
Tailor resumes: optimize bullet points against a job description, optionally generate cover letters.
Score ATS compatibility: run ATS structural audits and get compatibility scores.
Mask PII: redact email, phone, and address from resumes and export anonymized PDFs.
Scrape job postings: extract job details from LinkedIn, Greenhouse, Lever, Ashby, Wuzzuf, and similar sites.
Manage Pay-Per-CV: fetch localized pricing, purchase CV passes, and verify CV entitlements/unwatermarked access.
Track applications: add and list job applications on a Kanban board with statuses.
Allows extracting clean job requirements from Greenhouse job posting URLs, enabling AI agents to scrape and parse Greenhouse job listings.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Civify MCP Server tailor my resume to this job description and generate a cover letter"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Official Model Context Protocol (MCP) server for the Civify Career Platform.
Enables autonomous AI agents (Claude Desktop, Cursor, OpenCode, Qwen CLI, LibreChat, and custom agents) to directly interact with Civify's AI resume parsing, ATS scoring, resume tailoring, PII redaction, Pay-Per-CV monetization, and job application tracking engines.
Connect directly to Civify's managed cloud MCP server using the new Streamable HTTP transport:
Streamable HTTP URL: https://mcp.civify.cv/mcp
Legacy SSE URL: https://mcp.civify.cv/sse
Healthcheck: https://mcp.civify.cv/health
Add a custom connector with URL https://mcp.civify.cv/mcp — no config needed, authentication happens interactively in chat.
{
"mcpServers": {
"civify": {
"url": "https://mcp.civify.cv/mcp"
}
}
}{
"mcpServers": {
"civify": {
"url": "https://mcp.civify.cv/sse"
}
}
}Run locally using Node.js without pre-installing:
npx -y @civify/mcp-serverEdit your claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"civify": {
"command": "npx",
"args": ["-y", "@civify/mcp-server"]
}
}
}Add to your project's .cursor/mcp.json:
{
"mcpServers": {
"civify": {
"command": "npx",
"args": ["-y", "@civify/mcp-server"]
}
}
}npx -y @civify/mcp-serverRelated MCP server: laddro-career-mcp
No hardcoded or static API key is required at startup. The MCP server supports interactive, per-session authentication out of the box:
Sign In (civify_login): Users can authenticate with their Civify email/username and password. The agent automatically retrieves a session key (with 2FA support via civify_verify_2fa).
Register (civify_register): New users can create an account directly through the agent conversation.
Direct API Key (civify_set_api_key): Users who already hold a developer key (cv-fy-...) can provide it at any point in the chat or configure CIVIFY_API_KEY in client settings.
Tool | Description | Auth Required? |
| Set or activate an existing Civify API key ( | No |
| Sign in with email/username and password; auto-provisions session key | No |
| Complete two-factor authentication using the 6-digit email OTP | No |
| Register a new Civify account | No |
| Clear active credentials and reset session state | No |
| Get profile, active plan, remaining AI tokens, and CV pass credits | Yes |
Tool | Description | Auth Required? |
| Get localized Pay-Per-CV pricing (USD & EGP regional rates) | Public (No) |
| Purchase single CV pass or 3-pack (Card or Mobile Wallet) | Yes |
| Verify if a CV has an active 30-day unwatermarked pass and edit rights | Yes |
Tool | Description | Auth Required? |
| Scrape and extract requirements from job URLs (LinkedIn, Greenhouse, etc.) | Public (No) |
| Parse a PDF/DOCX/image resume into structured JSON schema | Yes |
| Tailor bullet points against a target job description + cover letter generation | Yes |
| Calculate ATS score and structural audit (document or JSON) | Yes |
| Redact sensitive personal contact information, export anonymized PDF | Yes |
| Render high-fidelity PDF from structured resume data | No |
Tool | Description | Auth Required? |
| Add a job application to the candidate's Kanban board | Yes |
| List all tracked job applications with status and dates | Yes |
Variable | Default | Description |
| (None) | Pre-seeds a default API key for the session. Can also be set interactively via |
Glama: List on https://glama.ai/mcp/servers.
PulseMCP: Listed in the curated registry at https://pulsemcp.com.
MIT © Civify Team
Get user account profile, subscription tier, remaining token balance, and CV credits.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does not state whether this is a read-only operation, whether authentication is required, what happens when not authenticated, or whether it hits rate limits. For a zero-param identity/balance tool these are relevant traits an agent would want to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single front-loaded sentence listing exactly what is returned. No filler, no restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so the description must explain what comes back, and it does list the returned fields. However, it says nothing about auth requirements, read-only nature, error behavior, or units for token/credit balances, which leaves gaps for a tool an agent will call to check state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so baseline 4 applies. The description identifies what the single implicit input (the calling user) yields, which is all the parameter-semantic content a zero-param tool can have.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get) and resource (user account) and enumerates exactly what is returned: profile, subscription tier, token balance, and CV credits. The sibling tools are all action tools (parse, tailor, score, mask, scrape, track) or a pricing lookup, so this read-only account tool is clearly distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (retrieve account info before doing work that consumes tokens or credits) but doesn't explicitly state when to use it versus alternatives. With no siblings competing for the same account-data purpose, the exclusion burden is low, but explicit when-to-use guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get localized Pay-Per-CV single unlock pricing (USD base and EGP regional pricing).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that pricing is localized with USD base and EGP regional currencies, which is useful behavioral context. However, it doesn't state whether pricing can change, whether it requires authentication, or how the result is structured. Adequate but with gaps for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single tight sentence that front-loads the verb and resource, then qualifies the currency scope. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-param, no-annotation, no-output-schema tool, the description covers what is fetched and the currency dimensions but omits authentication needs, rate limits, or how pricing is consumed. It is minimally adequate but leaves behavioral questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description confirms no input is needed by describing a pure lookup, which aligns with the empty schema. No further parameter semantics are possible.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Get) and resource (Pay-Per-CV single unlock pricing), with the added scope of localization and currencies. It is distinguishable from siblings like civify_get_account or civify_score_ats, though it doesn't explicitly name an alternative. Clear but no explicit sibling differentiation beyond the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is provided. The agent must infer that this is called before a Pay-Per-CV unlock to determine cost, but nothing states that context or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a CV and produce a sanitized, PII-masked version (redacts email, phone, physical address).
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path to resume file to redact. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it only covers the redaction scope. It does not say whether the original file is modified or preserved, where the sanitized output goes, whether authentication is required, or what the tool returns — all important for an upload/mutation-style tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no redundant clauses; the action and the redaction scope are both stated compactly and every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema and no annotations, the description covers the input action and redaction behavior but omits the return value and output-format details the agent needs to chain it with follow-up tools. Adequate but with a clear gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single file_path parameter, so the schema already carries the parameter semantics. The description adds nothing about accepted formats or path conventions, making the baseline 3 appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb pair (upload + produce) and a precisely scoped resource: a PII-masked CV with the redaction targets enumerated in parentheses (email, phone, physical address). This clearly separates it from siblings like civify_parse_cv or civify_tailor_cv, which handle the same CV artifact for different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance and no mention of alternatives, despite several siblings operating on the same CV (parse_cv, tailor_cv, score_ats). The agent must infer from the name alone that this is the privacy/sanitization path rather than the generic parsing path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a resume document (PDF, DOCX, image) into structured JSON schema containing contact details, work experience, education, skills, and projects.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Language code (e.g. 'en', 'ar', 'auto'). Default is 'auto'. | auto |
| file_path | Yes | Absolute or relative file path to the resume document (PDF, DOCX, image). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it does disclose the output contents (contact, experience, education, skills, projects), which is useful given no output schema. However it says nothing about cost, authentication, file-size limits, or failure modes, and a sibling pricing tool suggests the operation is paid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero waste that names the input formats and the returned schema sections in one pass.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since no output schema exists, the description appropriately enumerates the returned fields, making it nearly self-sufficient for a 2-parameter parse tool. Only error behavior and size limits are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented. The description only echoes the format list from file_path and adds no extra meaning about language handling or path resolution.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (parse) and resource (resume document) plus the supported formats and the resulting structured fields. It is clearly the extraction tool among siblings like tailor_cv, score_ats, and mask_pii, though it never names those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to choose this tool over siblings such as civify_tailor_cv or civify_score_ats, nor any prerequisites (e.g., payment via civify_get_pay_per_cv_pricing). Usage must be inferred from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate general ATS compatibility score and structural audit without needing a full JD.
| Name | Required | Description | Default |
|---|---|---|---|
| resume_id | Yes | UUID of an existing resume in Civify. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether the operation is read-only, what permissions are needed, how the score is returned, or whether the structural audit has side effects; the only extra context is that a full JD is not required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. Every part of the sentence adds useful information: the action, the two outputs, and the key condition for using the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with a fully documented schema and no output schema, the description covers purpose and the main usage condition. It omits details about the score format and what the structural audit includes, but those are not essential for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the single parameter 'resume_id' is fully documented in the schema as the UUID of an existing resume. The description adds no further parameter meaning, which is acceptable given the high schema coverage baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Calculate') and two concrete outputs ('general ATS compatibility score and structural audit'), so the tool's purpose is clear. It does not explicitly distinguish itself from siblings by name, though the 'without needing a full JD' clause implies a contrast with tools that do require one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without needing a full JD' gives an implied usage condition: use this when the full job description is unavailable. However, it does not name alternatives, state when not to use it, or explain what to do if a JD is available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scrape and extract structured job description, company name, requirements, and responsibilities from a job URL (LinkedIn, Greenhouse, Lever, Ashby, Wuzzuf).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the job posting. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses a scope constraint by naming supported sources (LinkedIn, Greenhouse, Lever, Ashby, Wuzzuf), which hints at failure modes for unsupported sites, but it omits auth requirements, rate limits, and whether the scrape is live/network-dependent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence with the core action front-loaded and the output fields enumerated compactly. The parenthetical platform list is slightly dense but earns its place by defining scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description adequately covers both the input (job URL) and the expected return (job description, company, requirements, responsibilities). Only the platform-failure behavior remains unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter whose schema description coverage is 100%, so the baseline is 3. The description adds only the notion that the URL points to a job posting and implies platform compatibility, but gives no syntax or format detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (scrape and extract) plus the resource (structured job data from a job URL) and enumerates the extracted fields. It is clearly distinct from siblings like civify_parse_cv, civify_tailor_cv, and civify_score_ats, which operate on CVs rather than job postings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer it applies when it holds a job posting URL. There is no explicit when-to-use vs. when-not-to-use guidance, no prerequisites, and no mention of what to do with an unsupported URL even though the tool names specific supported platforms.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tailor a candidate's resume against a target job description. Optimizes bullet points, highlights matching skills, and generates an optional targeted cover letter.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | No | Path to resume document file to tailor. | |
| job_title | No | Target job title. | |
| company_name | No | Target company name. | |
| job_description | Yes | The full text of the job description to tailor against. | |
| generate_cover_letter | No | Whether to generate a matching tailored cover letter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the tailoring actions but not critical traits: whether the source file is overwritten or a new document is produced, what the response contains, or that this appears to be a paid operation (given the civify_get_pay_per_cv_pricing sibling).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly written sentences, front-loaded with the primary action and followed by the specific transformations, with zero filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for the core purpose, but with no annotations and no output schema the description should say more about the result (does it return tailored text, a file path, a diff?) and cost/auth requirements implied by sibling pricing tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all five parameters. The description reinforces the optional cover-letter toggle via 'optional targeted cover letter,' but adds no format, length, or content expectations beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (tailor) and resource (resume/CV) against a target job description, and enumerates sub-actions: optimizing bullets, highlighting matching skills, and generating a cover letter. An agent can distinguish this from siblings like parse_cv or score_ats, though the description never explicitly names those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to choose this over civify_score_ats, civify_parse_cv, or civify_scrape_job, and no ordering/prerequisite hints (e.g., that a resume must be parsed first). Usage is implied by the verb only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a job application in the candidate's Civify Application Kanban tracker.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| status | No | APPLIED | |
| job_url | No | ||
| job_title | Yes | ||
| company_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies a write operation against a tracker but doesn't disclose key behaviors: how duplicates are handled, whether status transitions are validated, what side effects occur, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence with the resource and verb front-loaded. No waste, though minimal content limits its usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter mutation tool with zero schema descriptions, no annotations, and no output schema, the description is too thin. It omits parameter meanings, the status enum's role, and behavioral expectations the agent would need to call this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. Description mentions no parameters at all; the schema lists required company_name and job_title plus optional status enum, notes, and job_url but the description adds no semantics, no default status note, and no enumeration guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (record) and resource (a job application) with its destination (the Civify Application Kanban tracker). It's distinguishable from siblings like tailor_cv and score_ats, but doesn't explicitly delineate against them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance, no mention of alternatives, and no prerequisite context for recording versus other trackers. The description is purely declarative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0civify_get_accountcivify_get_pay_per_cv_pricingcivify_mask_piicivify_parse_cvcivify_score_atscivify_scrape_jobcivify_tailor_cvcivify_track_applicationScored across 8 tools
Each tool targets a distinct action and resource: parsing, tailoring, ATS scoring, PII masking, job scraping, application tracking, account retrieval, and pricing are all clearly separate. No two tools overlap in purpose.
All tools use the same civify_ prefix followed by a snake_case verb_noun pattern (e.g., civify_parse_cv, civify_tailor_cv). The convention is predictable and consistent throughout.
Eight tools is well-scoped for a CV and job application assistant, with each tool covering a distinct part of the workflow. No tools feel redundant or extraneous.
Core operations for CV parsing, tailoring, ATS scoring, PII masking, job scraping, and application recording are present. However, the application tracker lacks list, update, and delete operations, and account management only supports retrieval, leaving notable lifecycle gaps.
Auto-apply to jobs: matches your CV, tailors a fresh CV per posting, and applies for you.
Job platform for AI agents. Track tech jobs from companies that match your stack.
Manage job applications — jobs, companies, boards, notes, and profile — from your AI client.
Analyze job listings against your resume, track applications, and generate cover letters.
