Skip to main content
Glama

Create Cover Letter

create_cover_letter

Prepare a new cover letter from a job description and candidate information. Deducts credits from the user account. Prefer list_user_job_listings → present company + position options (list has no job description) → wait for the user to pick one → pass that id as jobListingId (omit companyName/role/jobPosition). Call get_user_job_listing only if you need the full posting. Only collect full company/role/jobPosition when no saved listing applies (creates a new listing). Prefer previously uploaded files from list_user_files when any exist — pass them as files. If list_user_files returns none, draft a personBio when you already have grounded candidate data and present it for confirmation or edits; if you lack usable background, ask them for experience, skills, and education. Never invent experience, skills, or education. Wait for explicit confirm (or edited text), then call this tool with the confirmed personBio (omit files or pass []). Always note that uploading a CV at https://www.coverlttr.com/settings/files improves quality for this and future letters. Prefer get_user_profile (and optionally get_cover_letter_cost) first so you know the user can afford the generation. After success, tell the user to open the returned viewUrl on the website for a proper formatted view and easy access to templates.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "create_cover_letter"
  }
}

Input Schema

NameRequiredDescriptionDefault
roleNoJob role / title. Required when jobListingId is not provided.
toneNoCustom tone content (required when toneTemplate is "custom")
filesNoPreviously uploaded files (CV/resume) from list_user_files. Prefer these when present. Optional when personBio holds user-confirmed background from chat.
languageNoISO language code, e.g. "en"en
jobMarketNoJob market index: 0=Europe, 1=NorthAmerica, 2=SouthAndCentralAmerica, 3=MiddleEastAndAfrica, 4=AsiaPacific
keyPointsNoUp to 7 key points to highlight (max 50 chars each)
personBioNoCandidate bio / background. When list_user_files returns no CV/resume, use a bio the user confirmed in chat (they may have edited your draft). Draft from grounded data when available; never invent experience, skills, or education. Prefer uploaded files when available; personBio alone is enough to create without files.
personNameNoCandidate full name
companyNameNoTarget company name. Required when jobListingId is not provided.
jobPositionNoFull job description. Required when jobListingId is not provided.
jobListingIdNoID from list_user_job_listings. When provided, company/role/job description are loaded from the saved listing — omit companyName, role, and jobPosition. Prefer this over manual fields whenever the user has a saved listing.
toneTemplateNoTone template key, e.g. energetic, professional, customenergetic
desiredLengthNoLength scale 0-4 (0=very short, 4=highly elaborate)
personProfessionNoCandidate profession / title

Output Schema

NameRequiredDescriptionDefault
idYes
kindYes
roleNo
titleNo
statusYes
excerptNo
viewUrlYes
keyWordsNo
languageNo
createdAtNo
authorNameNo
companyNameNo
countryCodeNo
creditsUsedNo
languageLabelNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare the generic non-read-only, non-destructive, non-idempotent profile; the description adds the critical behavior that this call deducts credits from the user account and should be gated on an affordability check. It also discloses the confirmation requirement, the anti-fabrication rule, and that the returned viewUrl should be surfaced for formatted viewing.

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?

It is front-loaded with purpose and cost impact before the workflow, and nearly every sentence carries operational instruction. It is sprawling and slightly repetitive (the files-vs-personBio preference and anti-fabrication rule resurface in both description and schema) and the mid-flow CV-upload URL note interrupts the sequence.

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?

For a 14-parameter orchestration tool with zero required fields and a dense sibling ecosystem, the description supplies the full call sequence, edge-case handling, and post-call guidance, while the existing output schema covers return values. Nothing an agent needs to invoke it correctly is missing.

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%, so a baseline 3 would be defensible, but the description adds real cross-parameter semantics: jobListingId mutually excludes companyName/role/jobPosition, and files vs personBio form a preference-ordered fallback with a confirmation step. Tone, language, and keyPoints are left entirely to the schema.

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 opening sentence names a specific verb and resource ('Prepare a new cover letter') and immediately scopes the inputs (job description + candidate information). It is clearly distinguishable from siblings like regenerate_cover_letter or list_user_cover_letters, which imply different operations.

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?

The description lays out an explicit decision tree: prefer list_user_job_listings and pass jobListingId, call get_user_job_listing only when the full posting is needed, fall back to manual company/role/jobPosition only when no saved listing applies, and check get_user_profile/get_cover_letter_cost first. It also names the when-not conditions (don't fabricate background, don't call before confirming).

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.

Resources