AI job search across 90+ countries (employer career pages + ATS feeds — Lever, Greenhouse, Workday), plus resume tailoring, cover letters, job detail & dashboard. Hosted; OAuth sign-in.
Show the signed-in user's Workopia dashboard (saved, tailored, and applied jobs + latest resume). Requires OAuth. Default action is list; optional status_filter (all | saved | tailored | applied). Use whenever the user asks to recall their Workopia activity: 'my applications', 'what jobs have I saved / applied to / tailored', 'show my dashboard', 'where did I leave off'. Returns a secure link to open the full dashboard on the web.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | ||
| status_filter | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true and destructiveHint=false. The description adds that it requires OAuth and returns a secure link to the web dashboard, providing useful behavioral context beyond the annotations.
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 four sentences, front-loading the core purpose, then authentication, then usage triggers, then output. Every sentence adds essential information with no wasted words.
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 read-only dashboard tool with no output schema, the description covers purpose, parameters, authentication, and output format. It does not cover error cases or rate limits, but overall is sufficient for an agent to use 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 description coverage is 0%, so the description must compensate. It mentions the optional status_filter with its enum values and the default action, but does not fully describe the action parameter (only that default is 'list'). More detail would improve this dimension.
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 shows the signed-in user's Workopia dashboard with specific components (saved, tailored, applied jobs + latest resume). It distinguishes from sibling tools like job_detail_tool by focusing on an overview.
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 explicitly provides example user queries that trigger this tool, such as 'my applications' and 'show my dashboard', giving clear when-to-use guidance. It implies alternatives exist for specific job details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render the full job-detail card for a specific job the user asks about. Use this whenever the user references a particular job from a prior search result — by number (#1, '1', 'first', 'the 3rd one', 'job 3'), by company name (partial or full, e.g. 'Morgan Stanley', 'Morstan'), by role/title phrase ('the analyst role', 'the credit risk one'), or by any 'show me this job' / 'tell me more about X' / 'view this role' style request. Resolving job_id from user reference: identify the right job from the most recent prior search/refine result (the numbered list you generated): (a) numeric/ordinal → the Nth job; (b) company name → substring match on Company field; (c) role/title phrase → substring match on Job Title field. Then pass that job's Job Id value from the prior search result's content text VERBATIM as job_id. Do NOT use a placeholder like 'JOB_1', '#1', or any synthetic id — only the real Job Id string from the prior result is server-valid. Required: job_id. OUTPUT BEHAVIOR: Render the response as a structured markdown card with the job's title (linked to the apply URL), company, location, salary, employment type, work mode, must-have skills, key requirements, highlights, and summary. Follow it with a brief next-step hint (e.g. 'Want to save it, find similar roles, ask about the company, or tailor your resume for this role?').
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | No | The id from a prior search result's job_cards[].card.id. Required. | |
| parameters | No | ||
| user_email | No | ||
| get_job_detail | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds behavioral context beyond annotations by detailing the output format (structured markdown card with specific fields) and a next-step hint. It does not contradict annotations. The added value is moderate but sufficient given annotation coverage.
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 appropriately sized and front-loaded with the main purpose. It uses three clear paragraphs: usage trigger, resolution details, and output behavior. Every sentence adds value, and the structure is logical and compact.
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?
Despite no output schema, the description fully explains the output (markdown card with nine fields) and next-step hint. It covers purpose, usage, parameter derivation, and output format. The tool's complexity is moderate, and the description provides complete context for an agent to invoke it 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 description coverage is low (25%), but the description compensates by thoroughly explaining the critical parameter job_id: it must be a real ID from prior search results, not a placeholder. It provides clear resolution rules. Other parameters (parameters, user_email) are not described, but the most important one is well-covered, raising the score above 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 clearly states the tool renders a full job-detail card for a specific job, using the verb 'render' and specifying the resource 'job-detail card'. It distinguishes from sibling tools (cover letter, dashboard, job, tailor resume) by focusing on individual job details from search results.
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 provides extensive guidance on when to use the tool, including numerous examples of user references and detailed resolution logic for deriving job_id. It implicitly distinguishes from siblings but lacks explicit instructions on when NOT to use this tool versus alternatives. The guidance is very comprehensive but missing explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search jobs across 90+ countries by title, location, salary, remote/hybrid work mode, or employment type. Find roles in tech, finance, product, design, marketing, and every other vertical — aggregated from 1000+ ATS sources globally. Default action is search; use refine when the user asks for more matches or gives feedback on a prior result set; use save to bookmark a job for the signed-in user (requires OAuth). REFINE PROTOCOL (action=refine has THREE distinct modes): (1) Pure continuation / 'show me more' / 'next batch' / 'another set' / 'more like these': pass refine_recommendations.exclude_ids = the full array of Job Id values from the most recent search/refine result's content text (verbatim) + refine_recommendations.session_id = prior response's session_id if present. Server returns next 10 unique jobs. (2) 'Show me more like #N' / 'similar to the Atlassian one' / 'jobs like #2': pass refine_recommendations.liked_indexes = [N] (1-based position from prior numbered list) + exclude_ids + session_id. Equivalently you may pass refine_recommendations.liked_job_ids = [<that job's **Job Id** value verbatim>]. Server seeds the recommendation from that job's title/skills/company profile. (3) 'Less like #N' / 'no more N-style jobs' / 'avoid jobs like that': pass refine_recommendations.disliked_indexes = [N] (or disliked_job_ids = []) + exclude_ids + session_id. Server suppresses similar jobs. All three modes: if you skip exclude_ids, the user sees duplicates — that's a failure. The handler layers exclude_ids with server-side AgentKit memory, so partial lists still work. NEVER invent 'JOB_1' / '#1' as job_id values — always use the real Job Id string from the prior result's content text. For detail requests (user asks about a specific job from the list, e.g. 'details for #1', 'show me this job', 'tell me more about '), DO NOT call this tool — call job_detail_tool instead. That separate tool binds to the job-detail widget card so the full job card renders in chat. OUTPUT BEHAVIOR: Render the search results as a numbered markdown list, one line per job, in this exact compact format: N. **[Job Title](View_Job_URL)** — Company · Location · Job Type · Compensation · Posted MMM DD. Embed the View Job URL as a markdown link on the title (so the user can click to apply). Keep URLs intact — don't strip parameters. Skip a field entirely if it's missing — never print 'N/A' placeholders. The numbered list IS the canonical user-facing answer. REQUIRED follow-up: after the list, output EXACTLY these two sentences as two parallel questions (same pattern for action=search and action=refine): Sentence 1 — 'Would you like to see full details on any of these? Reply with the number (#1), the company name, or the role title.' Sentence 2 — 'Or would you like to refine the list — what should change (work mode, level, salary, sector)?' These two sentences must be separate and parallel; do NOT merge them into one 'detail ... or refine' clause (that buries the detail CTA). Both questions must be asked every time after a search or refine result. When the user replies referring to a specific job from the list, identify which job they mean and call job_detail_tool immediately. Identifying the job (use flexibly — users rarely type '#N' literally): (a) any numeric or ordinal reference ('#1', '1', 'first', 'the 1st', 'top one', 'job 3', 'the third') → the Nth job in your prior numbered list; (b) a company name, partial or full ('Morgan Stanley', 'Morstan', 'Capital One') → case-insensitive substring match on the Company field of the prior list, pick the first match; (c) a role/title phrase ('the analyst role', 'the credit risk one') → case-insensitive substring match on the Job Title field. If multiple jobs match, prefer the earliest. Only if no reasonable match exists, ask a one-line clarifying question. Then pass that job's Job Id value from the prior search result's content text VERBATIM as job_id to job_detail_tool / tailor_resume_tool / cover_letter_tool. Do NOT invent a placeholder like 'JOB_1' or '#1' — those are not server-valid IDs. For save, pass job_id + optional job_title/company/job_url in save_job. Put search fields in search_jobs or parameters; refine in refine_recommendations; save in save_job.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | Optional; omitted = search. refine = after results/feedback; save = bookmark a job for the signed-in user. | |
| save_job | No | Save args. Required: job_id (from job_cards[].card.id in a prior search result). Optional: job_title, company, job_url. | |
| parameters | No | ||
| search_jobs | No | Search args. Required: city. Optional filters surface only when the user explicitly mentions them — omit otherwise. job_title+city uses indexed snapshot; company+city (optional job_title) uses legacy DB match. | |
| refine_recommendations | No | Refine args. Pass exclude_ids (array of Job Id strings from prior result) and session_id always. For 'more like #N': pass liked_indexes=[N] or liked_job_ids=[<Job Id>]. For 'less like #N': pass disliked_indexes=[N] or disliked_job_ids=[<Job Id>]. job_title/city optional — auto-filled from prior search via session memory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds substantial behavioral context beyond annotations: output format (numbered markdown list), required follow-up questions, refine modes, and warnings about inventing job IDs. No contradiction with annotations.
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?
Description is verbose (over 1.5k characters) and includes extensive protocol details. While well-structured, it could be more concise. Front-loaded with purpose, but refine protocol is lengthy.
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 complexity (5 parameters, nested objects, 3 actions, elaborate refine modes), the description covers all aspects: search, refine (3 modes), save, output formatting, follow-up, and error avoidance. No output schema is present, but output format is described.
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?
With 80% schema coverage, baseline is 3. Description adds critical meaning: 'city is required' (schema doesn't enforce), exact key names ('job_title' — not 'title'), and detailed refine parameter usage (liked_indexes, disliked_job_ids).
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?
Description explicitly states 'Search jobs across 90+ countries' and distinguishes from sibling tools by saying 'For detail requests ... call job_detail_tool'. The verb 'search' and resource 'jobs' are clear.
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?
Description provides explicit when-to-use: 'Default action is search; use refine when the user asks for more matches... use save to bookmark a job'. It also states when not to use: 'For detail requests... DO NOT call this tool — call job_detail_tool instead'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tailor a resume to a SPECIFIC job — TWO steps. STEP 1 (default; action omitted or 'prepare'): the server returns the job's full JD, its must-have skills/requirements, and the candidate's current resume, plus tailoring instructions. YOU (the model) then WRITE the tailored resume as JSON Resume, following the instructions — weave JD keywords into existing bullets only where the candidate genuinely has the experience, never fabricate experience/titles/dates/employers, keep all dates and company names, and flag any keyword you couldn't honestly add. STEP 2: call this tool again with action:'save', tailored_resume:, and job_id — the server renders a PDF and saves it to the candidate's Workopia dashboard (requires sign-in). Use whenever the user references a specific job to tailor for: 'tailor for #1', 'for Morgan Stanley', 'tailor my resume for this role: '. Resolving job_id (same rules as job_detail_tool): from the most recent prior search/refine result — (a) numeric/ordinal → the Nth job; (b) company name → Company-field match; (c) role/title phrase → Job-Title match — then pass that job's Job Id value VERBATIM. Do NOT use placeholders like 'JOB_1' or '#1'. For STEP 1 supply ONE of job_id (preferred — server fetches the JD from Mongo) OR job_description, plus the candidate's resume via resume_text / resume_content / resume_data. For general 'improve my resume' (no specific job), do NOT call this tool — call resume_tool action=improve instead. Note: the tailored resume is written by your AI client's own model — the assistant you are already using — so it works out of the box with nothing to configure; Workopia runs no LLM of its own and never charges for the AI.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | Omit or 'prepare' = STEP 1 (server returns JD + resume + instructions for you to tailor). 'save' = STEP 2 (pass tailored_resume; server renders a PDF and saves it to the dashboard; requires sign-in). | |
| job_id | No | ID of a job from a prior search/refine result. Use the **Job Id** value from the prior search result's content text VERBATIM. Server fetches full JD from Mongo. | |
| company | No | ||
| job_title | No | ||
| parameters | No | ||
| session_id | No | ||
| user_email | No | ||
| resume_data | No | PREFERRED shape — structured resume per utils/tailor/types.ts ResumeTree. Server, widget, and main-site PDF template all consume this exact shape. Collect these fields from the user before calling when possible. | |
| resume_text | No | User's resume content (plain text or JSON Resume as string). Fallback when resume_data is not provided. | |
| user_profile | No | Optional main-site profile object; used as a fallback source for name/title/contact/experience when resume_data and resume_text are both absent. | |
| tailor_resume | No | Optional wrapper containing the same fields above (legacy shape). | |
| resume_content | No | ||
| job_description | No | Full JD text when the user pastes it directly (alternative to job_id). | |
| tailored_resume | No | STEP 2 only: the tailored resume you generated, as a JSON Resume object (or a JSON string). The server renders it to PDF and stores it on profile.applications[job_id].resumeTailor. | |
| customization_level | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses the two-step process, the fact that the AI writes the resume, that STEP 2 requires sign-in, and that the server saves a PDF. Annotations indicate destructiveHint=true, which aligns with the save step. No contradictions.
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 detailed and front-loaded with the two-step overview, but somewhat verbose. However, every sentence adds necessary context for a complex multi-step tool, so it earns a 4.
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 15 parameters, no output schema, and nested objects, the description covers all essential aspects: steps, parameter usage, resolution rules, prerequisites, and constraints. No gaps identified.
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?
With 53% schema description coverage, the description adds significant value by explaining job_id resolution rules, the preferred shape for resume_data, action enum semantics, and fallback options. It compensates for the medium coverage.
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 purpose: 'Tailor a resume to a SPECIFIC job — TWO steps.' It distinguishes from siblings by specifying when to use resume_tool instead and mentions cover_letter_tool implicitly through context.
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?
Explicit usage guidance: 'Use whenever the user references a specific job to tailor for' and 'For general improve my resume (no specific job), do NOT call this tool — call resume_tool action=improve instead.' Also provides clear rules for job_id resolution.
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.
cover_letter_toolcover_letter_tooldashboard_tooljob_detail_tooljob_tooltailor_resume_toolClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Each tool has a clearly distinct responsibility: dashboard overview, job detail rendering, job search/refine/save, and resume tailoring. The job_tool description explicitly routes detail requests to job_detail_tool, preventing overlap.
All tool names use snake_case with a _tool suffix, giving a recognizable pattern. The mix of noun-based names (dashboard_tool, job_tool) and verb-based names (tailor_resume_tool) is a minor inconsistency, and job_tool is more generic than its siblings.
Four tools is well-scoped for a focused job-search and resume-tailoring assistant, and each tool covers a meaningful user workflow. There are no redundant or excessive tools.
The core search → detail → save → tailor → dashboard loop is covered, but the descriptions reference resume_tool and cover_letter_tool that are not exposed in the server, creating dead ends for those requests. There are also no unsave/delete or direct apply actions for saved jobs.