Skip to main content
Glama

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.5/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness3/5

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.

Resources