ResumeQuick

Read a job analysis

get_vacancy_detail

Read-only

Get one vacancy fit analysis by id, with match percentage, verdict, key strengths, gaps, recommendations, and a skill-by-skill requirements comparison, and app_url — the vacancy's page in ResumeQuick. Returns 'not_found' if the analysis does not exist or does not belong to the current user.

Input Schema

Name	Required	Description	Default
`input`	Yes

Output Schema

Name	Required	Description	Default
`id`	Yes
`url`	No	Link to the original job posting, when known.
`notes`	No	The user's notes on this vacancy.
`title`	Yes	Vacancy title (often includes company, e.g. 'Backend Engineer at Acme').
`status`	No	Job-tracker status: 'new' \| 'applied' \| 'interview' \| 'offer' \| 'rejected' \| 'accepted'.	new
`app_url`	Yes	Link to this vacancy's page in ResumeQuick, opened after signing in to this account; with a cover letter written it opens on the Cover Letter tab that keeps the letter.
`company`	No	Company name, when known.
`key_gaps`	No	Gaps in the CANDIDATE relative to the posting. Never carries remarks about the posting text itself — those live in input_quality.
`location`	No	Job location, when known.
`is_pinned`	No	The user pinned it to the top of their tracker; lists put pinned vacancies first.
`step_path`	No	Path on the ResumeQuick site where vacancy_step is done; null without one.
`analyzed_at`	Yes	ISO 8601 timestamp of when the vacancy was analyzed or, if never analyzed, added.
`is_archived`	No	Archived vacancies are hidden from the user's main list. Only an archived one can be deleted.
`vacancy_step`	No	The step inside this vacancy, the same one its page shows: tailor, cover_letter, apply, interview (it is at Interview), another (the analysis advises against it — the user's own next step from get_next_step is the one to take), or null (the analysis is not ready, or the case waits for the employer after an application).
`input_quality`	No	Quality of the posting text this analysis was based on. When truncated is true the score came from a fragment; analyze_tracked_vacancy re-runs it on the full text.
`key_strengths`	No	Strong points matching the vacancy.
`status_history`	No	Job-tracker status changes, oldest first; the history keeps the newest 100 events.
`analysis_status`	No	'completed' — analyzed; 'none' — tracked, never analyzed (match fields are null); 'processing' — an analysis is running right now; 'failed' — the last analysis failed. Lists only return 'completed' and 'none'; get_vacancy_detail returns every state.	completed
`chances_summary`	No	Short prose verdict on chances (e.g. 'Strong fit, apply soon').
`has_description`	No	Whether the posting text is stored on this vacancy (the text itself is never returned). False means it cannot be analyzed until the text is added — analyze_tracked_vacancy takes it as 'description'.
`recommendations`	No	Actionable steps to improve fit for this vacancy.
`tailored_resume`	No	The tailored resume copy linked to this vacancy, if one exists (created by apply_vacancy_resume_suggestions with target='copy' or create_resume_version with vacancy_id).
`verdict_summary`	No	Final verdict — 1–3 sentences explaining the recommendation.
`has_cover_letter`	No	Whether a cover letter for this vacancy is already written and kept on its Cover Letter tab (the text itself is never returned). cover_letter_stale true means it predates the latest re-analysis.
`match_percentage`	No	0–100, computed by the analysis; null for never-analyzed manual entries.
`verdict_category`	No	One of 'apply' \| 'consider' \| 'skip' \| 'not_eligible' \| 'invalid', or null if not categorized. 'not_eligible' means a hard eligibility blocker applies — the user cannot take this role as posted no matter how high match_percentage is; eligibility_blockers carries the reason.
`skills_comparison`	No	Skill-by-skill comparison of resume vs. vacancy requirements (the structured requirements view).
`cover_letter_stale`	No	The stored cover letter was written before the vacancy was analyzed again.
`resume_suggestions`	No	Structured resume-improvement suggestions for this vacancy, if generated. Empty until request_vacancy_resume_suggestions has run and completed. Their list order is the index space for apply_vacancy_resume_suggestions.
`cover_letter_options`	No	The options the stored cover letter was written with; null when there is no letter or it predates kept options. generate_cover_letter reuses each one it is not given.
`eligibility_blockers`	No	Why the user may not be able to take this role at all — work model, location, timezone, work authorization, relocation. Separate from skill fit and never reflected in match_percentage. Any 'hard' blocker means verdict_category is 'not_eligible', whatever the match score. Empty when nothing is known about the user or nothing conflicts.
`applied_suggestion_indices`	No	Indices (into resume_suggestions) that have already been applied to the resume.
`declined_suggestion_indices`	No	Indices (into resume_suggestions) of questions the person answered no to — the experience they ask about is not theirs.
`unchanged_suggestion_indices`	No	Indices (into resume_suggestions) whose last apply changed nothing: the resume states nothing they build on yet. Applying them again changes nothing until the resume gains what they need.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 25, 2026

addedOutput schema / properties / unchanged_suggestion_indices

Added value: +{
+  "description": "Indices (into resume_suggestions) whose last apply changed nothing: the resume states nothing they build on yet. Applying them again changes nothing until the resume gains what they need.",
+  "items": {
+    "type": "integer"
+  },
+  "title": "Unchanged Suggestion Indices",
+  "type": "array"
+}

Changed2 schema fields changedOct 17, 2026

changedOutput schema / properties / analyzed_at / description

Previous value: -"ISO 8601 timestamp."New value: +"ISO 8601 timestamp of when the vacancy was analyzed or, if never analyzed, added."

addedOutput schema / properties / is_pinned

Added value: +{
+  "default": false,
+  "description": "The user pinned it to the top of their tracker; lists put pinned vacancies first.",
+  "title": "Is Pinned",
+  "type": "boolean"
+}

First observedOct 15, 2026

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already cover read-only/non-destructive/closed-world, but the description adds real value beyond them: it discloses the per-user scoping ('does not belong to the current user') and the exact 'not_found' failure signal, which the agent can't infer from annotations. No rate limits or pagination concerns apply to a single-record fetch.

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?

A single front-loaded sentence: resource and identifier first, payload second, failure mode last. The return-field enumeration is somewhat redundant given an output schema exists, but it's compact and aids tool selection.

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?

With an output schema present, the description needn't explain return shape, and it correctly focuses on the not_found/ownership semantics instead. The one gap is the missing link to the sibling that produces the analysis in the first place, which would remove the remaining ambiguity.

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

Parameters2/5

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

Schema description coverage is 0%, so the description carries the burden, yet it only says 'by id' and never explains what a vacancy_id is, where to obtain it (analyze_vacancy output? get_recent_vacancies?), or whether it accepts the tracked-vacancy id. The one parameter's origin is the most likely source of a failed call and is left undocumented.

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

Purpose4/5

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

States a specific verb+resource ('Get one vacancy fit analysis by id') and enumerates the payload (match percentage, verdict, strengths, gaps, recommendations, skill comparison, app_url). It's clearly a read of an existing analysis, but it never names the sibling that creates one (analyze_vacancy / analyze_tracked_vacancy), which is the main ambiguity given how many 'analyze_*' tools exist.

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

Usage Guidelines3/5

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

Usage is only implied: fetching a single analysis by id. There is no statement of when to prefer this over analyze_vacancy, get_recent_vacancies, or search_vacancies, and no prerequisite mentioned (e.g. that the analysis must already exist). The id-origin hint ('as returned by other vacancy tools') lives in the schema, not the description.

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

All ResumeQuick tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.