Jobsuche, Lebenslauf-Erstellung & Karriereberatung — verfügbar über das Model Context Protocol für Claude Desktop, ChatGPT, Cursor, Windsurf und andere MCP-Clients.
Hinweis: Dies ist ein gehosteter Closed-Source-MCP-Server. Verbinden Sie sich über den unten stehenden öffentlichen Endpunkt — keine Installation oder API-Schlüssel erforderlich.
https://workopia.io/api/mcp-gptTransport: Streamable HTTP
Authentifizierung: Keine
Website: https://workopia.io
Related MCP server: JobGPT MCP Server
Tool | Funktion |
| Durchsuchen Sie Millionen von Jobs, die von Arbeitgeber-Karriereseiten und ATS-Feeds (Lever, Greenhouse) stammen. Kein Scraping. |
| Generieren Sie PDF-Lebensläufe mit mehreren Vorlagen (JSON-Lebenslaufformat). |
| KI-gestützte Beratung für den beruflichen Wandel und Analyse von Qualifikationslücken. |
Claude Desktop — fügen Sie dies zu claude_desktop_config.json hinzu:
{
"mcpServers": {
"workopia": {
"type": "streamable-http",
"url": "https://workopia.io/api/mcp-gpt"
}
}
} Cursor — .cursor/mcp.json:
{
"mcpServers": {
"workopia": { "url": "https://workopia.io/api/mcp-gpt" }
}
} ChatGPT — suchen Sie im ChatGPT App Store nach "Workopia".
MCP Registry: io.github.Shuangshuang007/workopia
OpenClaw ClawHub: Shuangshuang007/workopia
Workopia ist zum Start für alle kostenlos — kein API-Schlüssel, keine Registrierung, keine Zahlung. Standard-Ratenbegrenzungen:
job_tool, career_tool: unbegrenzt
resume_tool: 20 Anfragen pro Stunde und IP
Wenn Sie ein höheres Kontingent oder eine individuelle Vereinbarung benötigen, senden Sie eine E-Mail an shuang@heraai.one und wir werden direkt mit Ihnen zusammenarbeiten.
Entwickelt von HERAAI PTY LLC. Datenschutzrichtlinie: 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
