Skip to main content
Glama

Generate Cover Letter

aiapplyd_generate_cover_letter

Write a tailored cover letter from your saved resume for any job, or retrieve the letter already written for an application to revise it. Returns text and saves to your account.

Instructions

Write a cover letter for a specific job from the base resume saved on the user's AI Applyd account, in their own voice and free of recruiter cliches. Returns the finished letter as text and saves it to the account. Pass application_id instead to get the letter already written for that application (no new letter), with instructions to change it. Needs a resume on file (see aiapplyd_set_resume) and a paid plan (Hired in 30+); without either it says so and links the fix. Uses the user's AI credits. Do not use it for applications: aiapplyd_apply already writes a cover letter for every one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
company_nameNoName of the company you are applying to
instructionsNoWith application_id: what to change in that letter, in the user's own words.
application_idNoReturn the cover letter already written for this application (an id from aiapplyd_get_applications) instead of writing a new one.
job_descriptionNoFull text of the target job description. Pass with company_name, or pass application_id instead.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYes
sourceYesgenerated: newly written; application: the letter already prepared for application_id; refined: that letter, changed as asked.
companyNameYes
coverLetterYes
applicationIdYes
resumeBuildIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.8.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / application_id
      Added value: +{
      +  "description": "Return the cover letter already written for this application (an id from aiapplyd_get_applications) instead of writing a new one.",
      +  "exclusiveMinimum": 0,
      +  "maximum": 9007199254740991,
      +  "type": "integer"
      +}
    • addedInput schema / properties / instructions
      Added value: +{
      +  "description": "With application_id: what to change in that letter, in the user's own words.",
      +  "maxLength": 2000,
      +  "type": "string"
      +}
    • changedInput schema / properties / job_description / description
      Previous value: -"Full text of the target job description"New value: +"Full text of the target job description. Pass with company_name, or pass application_id instead."
    • removedInput schema / required
      Removed value: -[
      -  "job_description",
      -  "company_name"
      -]
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": false,
      +  "properties": {
      +    "applicationId": {
      +      "anyOf": [
      +        {
      +          "type": "number"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ]
      +    },
      +    "companyName": {
      +      "type": "string"
      +    },
      +    "coverLetter": {
      +      "type": "string"
      +    },
      +    "resumeBuildId": {
      +      "anyOf": [
      +        {
      +          "type": "number"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ]
      +    },
      +    "source": {
      +      "description": "generated: newly written; application: the letter already prepared for application_id; refined: that letter, changed as asked.",
      +      "enum": [
      +        "generated",
      +        "application",
      +        "refined"
      +      ],
      +      "type": "string"
      +    },
      +    "url": {
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "coverLetter",
      +    "companyName",
      +    "source",
      +    "resumeBuildId",
      +    "applicationId",
      +    "url"
      +  ],
      +  "type": "object"
      +}
  2. First observedv1.3.0

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the minimal annotations (readOnlyHint false, etc.), the description discloses that the tool saves the letter to the account, uses AI credits, requires a resume and paid plan, and gracefully handles missing prerequisites by informing the user. It also reveals the two operational modes and the stylistic behavior of avoiding recruiter cliches. No contradictions with annotations.

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 information-dense yet efficient, front-loading the core purpose and then covering prerequisites, alternative usage, and exclusions. Every sentence contributes necessary detail without redundancy. The structure flows logically from action to caveats to alternative.

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?

Given the tool's complexity (two modes, prerequisites, credit usage) and the presence of an output schema, the description covers all essential aspects: the two modes, what happens when prerequisites are missing, the credit usage, and the alternative tool. Nothing critical is omitted for an agent to call 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 coverage is 100% so baseline is 3. The description adds value by explaining the relationship between parameters: company_name and job_description are used together, while application_id is an alternative, and instructions only apply when application_id is provided. This relational context is not in the schema and helps correct usage.

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 writes a cover letter from the user's base resume for a specific job, and explicitly distinguishes it from aiapplyd_apply by warning not to use it for applications. The verb 'write' and resource 'cover letter' are specific, and the alternative mode via application_id is clearly explained.

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 gives explicit when-to-use guidance: use for writing a new cover letter, or pass application_id to retrieve an existing one. It also states exclusions (aiapplyd_apply already writes cover letters for applications) and prerequisites (resume on file and paid plan), including what happens if they're missing. This leaves no ambiguity about when to choose this tool.

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