Skip to main content
Glama

Workopia — Job Search

job_tool

Destructive

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionNoOptional; omitted = search. refine = after results/feedback; save = bookmark a job for the signed-in user.
save_jobNoSave args. Required: job_id (from job_cards[].card.id in a prior search result). Optional: job_title, company, job_url.
parametersNo
search_jobsNoSearch 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_recommendationsNoRefine 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.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide readOnlyHint=false and destructiveHint=true. Description adds context: save requires OAuth, the output format, and the required follow-up sentences. It warns about consequences of missing exclude_ids (duplicates). However, the destructive aspect isn't clarified beyond save (which creates a bookmark).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Though long, the description is well-structured with clear sections (search, refine, save, output behavior, follow-up). Front-loaded with key usage. Not overly concise but earns its length through necessary detail for a complex tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers all actions comprehensively: input schema, output behavior, follow-up protocol, error avoidance, prerequisites (OAuth for save), and relationships to sibling tools. No output schema, but the description fully compensates with precise formatting instructions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is high (80%), and description adds significant value: outlines three refine modes, cautions about passing parameters only when explicitly mentioned, and clarifies when to use exact key names. For example, it explains that 'job_title+city uses indexed snapshot' vs 'company+city uses legacy DB match.'

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: searching jobs across 90+ countries with various filters. It distinguishes from siblings like job_detail_tool (details) and cover_letter_tool/ tailor_resume_tool (other actions). The verb 'search' plus resource 'jobs' with scope is explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit when-to-use guidance: 'Default action is search; use refine when the user asks for more matches or gives feedback; use save to bookmark for signed-in user.' Also tells when NOT to call this tool (for details, use job_detail_tool) and when to use alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation4/5

The four tools serve clearly distinct purposes: dashboard overview, job search/refine/save, job detail rendering, and resume tailoring. job_tool and job_detail_tool could be confused by name alone, but the descriptions explicitly route detail requests to job_detail_tool.

Naming Consistency3/5

All names use snake_case and share the '_tool' suffix, but there is no consistent verb_noun pattern: dashboard_tool, job_detail_tool, and job_tool are noun phrases while tailor_resume_tool is the only verb-led name. The pattern is readable but mixed.

Tool Count5/5

Four tools is well-scoped for a job-search assistant. Each tool covers a distinct user need—searching, viewing details, viewing the dashboard, and tailoring a resume—without unnecessary bloat.

Completeness3/5

Core workflows are covered: search, refine, save, view details, dashboard, and resume tailoring. However, the descriptions reference resume_tool and cover_letter_tool which are not present in the tool set, creating potential dead ends and notable gaps in the advertised surface.