The Workopia MCP server provides tools for job searching, resume management, cover letter generation, and career planning — powered by your own AI client.
Search for jobs (job_tool): Search millions of live job listings across 90+ countries from employer career pages and ATS feeds. Filter by location, job title, company, work mode, employment type, and more. Optionally pass your resume or profile for closer matching.
Refine job results (job_tool with action=refine): Refine prior search results based on feedback or preferences.
Get job details (job_tool with action=detail): Retrieve full details for a specific listing — salary, requirements, skills, and company info.
Tailor your resume (resume_tool with action=tailor): Optimize or rewrite your resume content to better match a specific job description.
Generate a formatted resume (resume_tool with action=generate): Create a styled, formatted, or downloadable PDF resume using various templates (e.g. workopia_classic, workopia_modern). Accepts plain text or JSON Resume format; returns a preview URL and PDF download URL.
Draft cover letters (cover_letter_tool): Generate a cover letter tailored to a specific role.
View your dashboard (dashboard_tool): Access your Workopia dashboard to see saved, tailored, and applied jobs, plus your latest resume.
Career transition planning (career_tool): Get career advice based on your current role, years of experience, skills, industry, and location.
Listed on the MCP Registry (io.github.Shuangshuang007/workopia), providing discoverability and distribution through GitHub's MCP ecosystem.
Integrates with Greenhouse ATS feeds to provide job search capabilities, allowing users to access millions of jobs sourced directly from employer career pages and Greenhouse systems.
Available as an npm package (@shuang_workopia/workopia-mcp) for distribution and installation, making the MCP server accessible through the npm ecosystem.
Job search, resume tailoring, cover letters & application tracking — available via the Model Context Protocol for Claude Code, Claude Desktop, Cursor, Windsurf, and other MCP clients.
Note: This is a hosted MCP server. Connect via the public endpoint below and sign in with Workopia (OAuth) — no API key to manage. All tools require a free Workopia sign-in; searching, job detail, resume tailoring, cover letters, and your dashboard are all scoped to your account. Resume tailoring and cover letters run on your own AI client's model — Workopia hosts no LLM and never charges for AI.
https://workopia.io/api/mcp-jobsTransport: Streamable HTTP
Auth: OAuth 2.0 (Dynamic Client Registration + PKCE; handled automatically by the client)
Website: https://workopia.io
Related MCP server: JobGPT MCP Server
/plugin marketplace add workopia/workopia-mcp
/plugin install workopia-jobsOn first tool use, Claude Code opens the Workopia OAuth flow in your browser; the token is then stored and refreshed automatically.
There is no separate GitHub-repository account and no API key to create. The first time an MCP client calls a Workopia tool, it opens the Workopia authorization page in your browser. Sign in with an email code, Google, LinkedIn, or GitHub.
If that verified email already has a Workopia profile, the MCP connection uses it.
Otherwise Workopia creates a minimal profile for that verified email.
The MCP client stores and refreshes its OAuth token. Disconnect or remove Workopia in the client to revoke its local connection.
Using the same verified email from another supported client connects activity to the same Workopia profile; it does not create a separate MCP-only account.
OAuth uses Authorization Code + PKCE and Dynamic Client Registration. Never paste a Workopia password, email code, OAuth token, or resume into this repository or a GitHub issue.
Tool | What it does |
| Search millions of live jobs across 90+ countries (employer career pages + ATS feeds — Lever, Greenhouse, Workday). Save a job to your account (sign-in). |
| Full detail for a single job — salary, requirements, skills, company. |
| Tailor your resume to a specific job description. |
| Draft a cover letter for a specific role. |
| Open your Workopia dashboard — saved, tailored & applied jobs + latest resume (sign-in). |
Claude Desktop — add to claude_desktop_config.json:
{
"mcpServers": {
"workopia": {
"type": "streamable-http",
"url": "https://workopia.io/api/mcp-jobs"
}
}
}Cursor — .cursor/mcp.json:
{
"mcpServers": {
"workopia": { "url": "https://workopia.io/api/mcp-jobs" }
}
}ChatGPT — search "Workopia" in the ChatGPT App Store.
MCP Registry: io.github.Shuangshuang007/workopia
OpenClaw ClawHub: Shuangshuang007/workopia
Free at launch. A free Workopia sign-in (OAuth) is required to use the tools — searching, job detail, resume tailoring, cover letters, and your dashboard. Need a higher quota or a custom arrangement? Email shuang@heraai.one.
Authenticated tool actions such as job searches, job views, saved jobs, applications, resume operations, and cover-letter creation may be associated with your Workopia profile so your dashboard and history work across supported MCP clients. Workopia records the integration family (for example MCP) and, when the OAuth client identifies itself, the client type (for example Codex, Claude Code, Cursor, or Windsurf).
Conversation transcripts are not collected by this MCP server. Activity records do not contain OAuth tokens or raw resume text. Resume content needed for a requested resume operation is handled under the Workopia privacy policy linked below.
Found something broken or want a tool improved? Open an issue — this repo is where we track bugs and feedback for the Workopia MCP server and Claude Code plugin. For account, billing, or anything private, email shuang@heraai.one.
Built by HERAAI PTY LLC. Privacy policy: https://workopia.io/privacy
Career transition / planning — same as career_transition_advice. Pass fields in career_transition_advice or career or top-level.
| Name | Required | Description | Default |
|---|---|---|---|
| career_transition_advice | No | ||
| career | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It does not indicate if the tool reads or writes data, nor any side effects or permissions needed.
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 short (one sentence), which is concise, but it lacks essential clarity. Conciseness is not beneficial when it sacrifices understanding.
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?
Given the nested objects, lack of output schema, and no annotations, the description is incomplete. It does not explain return values, expected behavior, or how to use the tool effectively.
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 0%, but the description only says 'Pass fields in career_transition_advice or career or top-level.' It does not explain what the parameters mean or how they affect output.
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 says 'Career transition / planning' but then adds 'same as career_transition_advice' without explaining what career_transition_advice is, creating confusion. It does not clearly state the tool's function or action.
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 use this tool versus siblings (job_tool, resume_tool). The instruction about passing fields in different places is about parameter format, not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Default: find job listings (search). If action is omitted, the request is treated as search. For closer matching on recent roles, pass resume_text and/or user_profile with search (still action=search); do not use any other tool name for this. Use refine when there are prior Hera job results or explicit user feedback. Use detail only with a specific job_id. Put search fields in search_jobs or parameters; refine in refine_recommendations; detail in get_job_detail.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | Optional; omitted = search. refine = after results/feedback; detail = requires job_id. | |
| search_jobs | No | Search args: city/location is always required. job_title+city uses indexed snapshot; company+city (optional job_title) uses legacy company+location DB match for non-empty results. Optional workMode, employmentType, workModeStrict, resume_text, user_profile, profile_aware. | |
| refine_recommendations | No | ||
| get_job_detail | No | job_id (required for detail), optional user_email | |
| parameters | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses behavioral traits such as the default action and required fields for different search modes (e.g., city/location always required, differences between job_title+city and company+city). However, it does not explicitly state whether the tool is read-only or mention rate limits, auth, or side effects.
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 well-structured with clear instructions per action, but is somewhat lengthy. Each sentence earns its place, though minor redundancy exists (e.g., emphasizing default action twice). Overall, it's concise enough given the complexity.
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 tool with 5 parameters, nested objects, and no output schema, the description covers core usage but lacks details on refine_recommendations and parameters. It does not describe return values or expected output, which is a gap given the absence of an output schema.
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 60%. The description adds significant meaning for the action enum and search_jobs object (e.g., required fields, mode differences). However, refine_recommendations and parameters lack any description beyond being objects, missing an opportunity to fully compensate for the coverage gaps.
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 clearly states the tool's default action is to find job listings via search, and explains three distinct actions (search, refine, detail). It instructs not to use any other tool for this purpose, but does not explicitly differentiate from sibling tools career_tool and resume_tool, leaving some ambiguity.
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?
Provides explicit guidance on when to use each action: search as default (or when starting), refine after prior results/feedback, and detail with a specific job_id. It also clarifies when to include resume_text/user_profile, demonstrating clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for ALL resume-related actions. action omitted or action=tailor: ONLY when the user wants to improve, optimize, tailor, or rewrite a resume (text optimization). action=generate: MANDATORY when the user asks for generate/create resume, resume template, styled or formatted resume, downloadable resume, PDF resume, or preview/shareable resume — do NOT use tailor for those. INPUT for generate: resume_text or resume_content (plain text or JSON Resume as string), and/or json_resume (JSON Resume object: basics, work[], education[], skills[] per jsonresume.org — preferred for structured data). At least one of those is required. Optional template_key (Workopia registry key; omit defaults to Workopia Classic / workopia_classic). Legacy alias hera_classic accepted. OUTPUT for generate: template_name, url (preview), download_url (PDF) from the tool only — never invent URLs; never return raw PDF/HTML/base64. OUTPUT for tailor differs (e.g. optimizedResume text).
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | Omitted or "tailor" = improve/optimize/tailor/rewrite content only. "generate" = MANDATORY for PDF, downloadable resume, template, styled/formatted output, create/generate resume, or shareable/preview link — never use tailor for those intents. | |
| template_key | No | Optional for action=generate. MUST be one of enum values only. Omit = Workopia Classic. Do NOT invent keys; use workopia_flexbox for tech-heavy layout, workopia_elegant for professional/corporate, workopia_designer for product/designer roles. Unknown keys are ignored server-side with fallback. | |
| template_keys | No | Optional for action=generate; up to 5 registry template keys to render multiple PDFs in one call. | |
| session_id | No | Optional; correlates GPT session with synthetic owner email for GridFS access (gpt+session_id@internal.hera). | |
| resume_text | No | For tailor: required (resume body). For generate: optional if json_resume or object resume_content is set. Plain text or JSON Resume as a string. Alias: resume_content when string. | |
| json_resume | No | Optional for action=generate. JSON Resume object (https://jsonresume.org/schema/): basics, work, education, skills, etc. Same structure library themes consume. Takes precedence over resume_text when both are sent. | |
| tailor_resume | No | Payload for tailoring (same shape as legacy tailor_resume). | |
| parameters | No | Shortcut: tailor fields at top level (excluding action). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description takes full burden and discloses key behaviors: different outputs for tailor vs generate, input requirements, template fallback behavior, and warnings like 'never invent URLs' or 'never return raw PDF/HTML/base64'. Does not cover auth or rate limits, but adequately describes core behavior.
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 structured with clear sections (action, input, output) and is front-loaded with the main distinction. It is somewhat lengthy but every sentence adds necessary details; no obvious fluff.
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?
With 8 parameters, no output schema, and no annotations, the description covers the main aspects: actions, inputs, output examples, and template handling. Could include more on tailor output or error handling, but it is sufficient for a tool of this complexity.
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%, yet the description adds significant value beyond schema descriptions. For example, it recommends specific template keys for different layouts, explains input precedence (json_resume over resume_text), and clarifies legacy aliases. This goes well beyond what the schema alone provides.
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 clearly states it is for 'ALL resume-related actions' and distinguishes between two main use cases: tailor (text optimization) and generate (creation with templates/PDF). This is specific and actionable, covering the full scope of the tool.
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?
Provides explicit when-to-use guidelines for tailor vs generate, e.g., 'do NOT use tailor for those intents' and 'MANDATORY when the user asks for generate/create resume, ...'. However, it does not compare with sibling tools (career_tool, job_tool), though the description implies it covers all resume tasks.
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. Dates show when Glama detected each change.
v1.0.0career_tooljob_toolresume_toolThe three tools cover distinct domains: career planning, job search, and resume actions. Some minor overlap possible between career_tool and resume_tool, but descriptions clearly separate them.
All tool names follow a consistent pattern of lowercase words joined by underscores, ending with '_tool'. This is predictable and uniform.
With only 3 tools, the server covers a broad domain. While each tool encapsulates multiple actions, the count feels slightly low for the range of functionality implied.
Core features like career advice, job search, and resume creation are present. Missing common features like cover letters or application tracking suggest notable gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Public MCP server for discovering open jobs. Search, filter, and get application links.
Generate tailored, ATS-optimized resume PDFs and cover letters from a job description, over MCP.
GetJobzi MCP server for job search, application tracking, and career forecasting.
Hosted MCP server for AI-driven data ops. Create apps, manage schemas, and CRUD structured data.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/workopia/workopia-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
