Skip to main content
Glama
JonniThorpe

job-radar-mcp

by JonniThorpe
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Render a CV tailored to an offer

render_cv
DestructiveIdempotent

Generates a one-page CV tailored to a job offer from existing profile data, choosing and ordering projects, experience, bullets, and tags without inventing content.

Instructions

Writes output/cv-.html, a version of the CV tailored to one offer: it chooses which projects, which lines of each project, which bullets and which tags go in, and in what order. If not everything fits, trim lines inside each project before dropping a whole project. It CANNOT invent content: everything must already exist in profile/cv-data.json, and the whole call fails if you cite an id or tag that is not there. Only headline, summary and location accept free text, because they are framing. Omit any section to keep it complete as is. Do NOT call it on your own after an analysis: propose the tailoring and wait for the user to ask for it.

Input Schema

NameRequiredDescriptionDefault
noteNoWhy these choices for this offer. Stored as a comment inside the HTML, invisible when printed.
stackNoTech Stack groups to show, in order. Omit it to include them all unchanged.
offerIdYesId of the offer this CV is tailored to, format YYYY-MM-company. It names the output file.
summaryNoSidebar summary. Free text, but it may only reorder and emphasise what is already true in cv-data.json: do not add technologies or experience that are not there. About 300 characters; longer pushes the rest of the column off the page.
headlineNoHeadline under the name. Free text (accepts <br>): it is framing, not a factual claim. Never claim a job title the person has not held. Omit it to keep the one in cv-data.json.
locationNoLocation line in the contact block. Free text: where the person lives and where they can work. E.g. 'Northbridge · Open to remote'. Omit it to keep the one in cv-data.json.
projectsNoProjects to show, in order: the bare id for the whole project, or {id, lines} to keep only the lines that matter for this offer. This is where tailoring pays off most: put first the ones that touch the offer and, if it does not fit, trim lines before dropping a whole project. Omit it to include them all.
educationNoEducation ids, in order. Omit it to include them all.
experienceNoJobs to show, in order. Omit it to include them all.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior4/5

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

Adds substantial behavior beyond the idempotentHint/destructiveHint annotations: content provenance (everything must already exist in profile/cv-data.json), an all-or-nothing failure mode when citing a missing id or tag, and the free-text boundary limited to headline/summary/location. It does not explicitly state that it overwrites an existing output/cv-<id>.html file, which is the main destructive consequence implied by destructiveHint=true.

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?

Front-loads the write action and output path, then layers constraints and the do-not-auto-call rule. Dense but every sentence carries a rule; slightly long-winded in the projects paragraph where the schema already repeats the trim-before-drop guidance.

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?

No output schema exists, and the description covers the return artifact (file path, invisible stored comment), the validation failure mode, and the invocation workflow. An agent has everything needed to call it correctly and safely.

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 100% (baseline 3), but the description adds real meaning: which fields accept free text versus must reference existing ids, the omit-to-keep-unchanged convention, and the rationale that projects is where tailoring pays off most. That goes beyond the schema's own property descriptions.

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?

States a specific verb and artifact ('Writes output/cv-<id>.html, a version of the CV tailored to one offer') and immediately scopes it to selecting projects, lines, bullets and tags. No sibling (record_gap, save_offer, list_gaps, etc.) operates on CV rendering, so the distinction is unambiguous.

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?

Explicitly states when NOT to call it ('Do NOT call it on your own after an analysis: propose the tailoring and wait for the user to ask for it') and gives a fallback ordering rule ('trim lines inside each project before dropping a whole project'). This is a clear workflow constraint an agent would otherwise violate.

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

Deploy Server

Other Tools