Skip to main content
Glama

Generate Cover Letter

getmattered_generate_cover_letter
Destructive

Writes a cover letter for a job, or reads or revises an application's letter by application_id. Sends nothing. Uses AI credits. It also works without a resume-builder document. It uses resume_text, a resume the user pasted or attached in this conversation, else the base resume uploaded to their account, else their resume-builder document.

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": "getmattered_generate_cover_letter"
  }
}

Input Schema

NameRequiredDescriptionDefault
resume_textNoThe resume the user pasted or attached in this conversation, as plain text. Left out, the resume already on the user's GetMattered account is used.
company_nameNoName of the company the user is applying to
instructionsNoWith application_id: what to change in that letter, in the user's own words.
application_idNoAn application (an id from getmattered_get_applications). With it, the answer is that application's prepared cover letter.
job_descriptionNoFull text of the target job description. Used with company_name, or replaced by application_id.

Output Schema

NameRequiredDescriptionDefault
urlYes
sourceYesgenerated: newly written; application: the letter already prepared for application_id; refined: that letter, changed as asked.
setupStepNoPresent while account setup is open: the first setup step.
companyNameYes
coverLetterYes
resumeSourceNoWhich resume a new letter was written from.
applicationIdYes
resumeBuildIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / application_id / description
      Previous value: -"An application (an id from getmattered_get_applications) whose cover letter is returned instead of a new one."New value: +"An application (an id from getmattered_get_applications). With it, the answer is that application's prepared cover letter."
    • changedOutput schema / properties / setupStep / description
      Previous value: -"Set while account setup is open: the step to take first."New value: +"Present while account setup is open: the first setup step."
  2. Changed4 schema fields changed
    • changedInput schema / properties / application_id / description
      Previous value: -"Return the cover letter already written for this application (an id from getmattered_get_applications) instead of writing a new one."New value: +"An application (an id from getmattered_get_applications) whose cover letter is returned instead of a new one."
    • changedInput schema / properties / company_name / description
      Previous value: -"Name of the company you are applying to"New value: +"Name of the company the user is applying to"
    • changedInput schema / properties / job_description / description
      Previous value: -"Full text of the target job description. Pass with company_name, or pass application_id instead."New value: +"Full text of the target job description. Used with company_name, or replaced by application_id."
    • changedInput schema / properties / resume_text / description
      Previous value: -"The resume the user pasted or attached in this conversation, as plain text. Omit it to use the resume already on the user's GetMattered account."New value: +"The resume the user pasted or attached in this conversation, as plain text. Left out, the resume already on the user's GetMattered account is used."
  3. Changed1 schema field changed
    • addedOutput schema / properties / setupStep
      Added value: +{
      +  "description": "Set while account setup is open: the step to take first.",
      +  "type": "string"
      +}
  4. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description adds genuinely new behavioral facts: it sends nothing, it consumes AI credits, and it has a three-tier resume fallback chain. The notable gap is that it never explains what the destructiveHint actually destroys — presumably an existing letter is overwritten when revising — which is the single most important side effect for an agent to know.

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 mode enumeration and the 'Sends nothing / Uses AI credits' constraints are front-loaded where an agent will see them. The final sentence about resume_text is a long chained clause that is harder to parse than it needs to be, but no sentence is filler.

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, return values need no explanation, and the description covers modes, cost, and input fallbacks adequately for a 5-parameter tool. The remaining hole is the destructive overwrite behavior on the revise path, which an agent should understand before calling it on an existing application.

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 coverage is 100%, so the baseline is 3. The description does add some meaning beyond the schema, notably the resume-builder fallback tier and the fact that application_id replaces company_name/job_description, but the schema already documents most of this, so the marginal gain is modest.

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?

The description names a specific verb and resource ('Writes a cover letter for a job') and enumerates the three modes: generate, read, and revise by application_id. It is clear what the tool produces, but it never distinguishes itself from the sibling getmattered_refine_application_documents, which plausibly overlaps with the 'revises' mode.

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?

It gives concrete selection conditions: pass application_id to read or revise an existing letter, otherwise supply company_name plus job_description to generate one. It also states the tool works without a resume-builder document. It stops short of naming an alternative tool for the revise case, so the routing against refine_application_documents is left implicit.

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.