Skip to main content
Glama

Workopia — Job Search

by io.github.workopia

job_detail_tool

Read-only

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?').

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
job_idNoThe id from a prior search result's job_cards[].card.id. Required.
parametersNo
user_emailNo
get_job_detailNo

Schema Changelog

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

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds detailed output behavior (structured markdown card) and resolution logic, providing useful context beyond annotations without contradiction.

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?

The description is long but well-structured: purpose first, then usage, resolution logic, output format, and next-step hint. Every sentence is informative; no wasted words, though it could be slightly more concise.

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

Completeness4/5

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

Given the complexity (4 parameters, nested objects, no output schema), the description covers the main parameter thoroughly and describes output behavior. It lacks explanation for other parameters but is still fairly complete for the core use case.

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

Parameters3/5

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

Schema description coverage is low (25% for job_id). The description thoroughly explains job_id resolution, but ignores other parameters (user_email, get_job_detail). It adds value for the main parameter but does not fully compensate for the coverage gap.

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 it renders the full job-detail card for a specific job, with specific verb 'Render' and resource. It distinguishes from siblings by focusing on reference to a prior search result, not listing or other actions.

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

Usage Guidelines4/5

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

The description explicitly tells when to use: whenever the user references a particular job from a prior search, with examples. It implies alternatives (other tools) by context but does not name them explicitly, so one step below the highest standard.

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

All Workopia — Job Search toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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.

Resources