Skip to main content
Glama

Resume PDF or Draft

aiapplyd_build_pdf

Create an editable resume draft with up to 2,000 characters saved in its summary section. This tool does not split raw text into experience, education or skills. Complete those sections in the builder before downloading a PDF.

Instructions

Create an editable resume draft with up to 2,000 characters saved in its summary section. This tool does not split raw text into experience, education or skills. Complete those sections in the builder before downloading a PDF. Templates: modern, classic, or minimal. Private by default; set make_public to true only if the user explicitly asks to share the draft. Requires a paid plan (Hired in 30+). Do not use it to rewrite a resume; use aiapplyd_optimize_resume. resume_text is optional. Without it, nothing is created: the tool returns the link to the PDF of the resume already on the user's account, and a public link only when make_public is true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
templateNoResume template style (default: classic)
make_publicNoPublish a public share link. Anyone with the link sees the resume INCLUDING its contact details. Defaults to false (private). Only set true when the user explicitly asks to share it.
resume_textNoFull text of the resume. Omit it to get the PDF of the resume already on the user's account.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYes
templateYes
publicUrlYes
documentIdNoThe resume document whose PDF the link opens, when no draft was created.
resumeBuildIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.9.0
    • changedInput schema / properties / resume_text / description
      Previous value: -"Full text of the resume"New value: +"Full text of the resume. Omit it to get the PDF of the resume already on the user's account."
    • removedInput schema / required
      Removed value: -[
      -  "resume_text"
      -]
    • addedOutput schema / properties / documentId
      Added value: +{
      +  "description": "The resume document whose PDF the link opens, when no draft was created.",
      +  "type": [
      +    "number",
      +    "null"
      +  ]
      +}
    • changedOutput schema / properties / resumeBuildId / type
      Previous value: -"number"New value: +[
      +  "number",
      +  "null"
      +]
    • changedOutput schema / properties / template / type
      Previous value: -"string"New value: +[
      +  "string",
      +  "null"
      +]
  2. Changed2 schema fields changedv1.8.5
    • removedOutput schema / properties / publicUrl / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / publicUrl / type
      Added value: +[
      +  "string",
      +  "null"
      +]
  3. Changed2 schema fields changedv1.8.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": false,
      +  "properties": {
      +    "publicUrl": {
      +      "anyOf": [
      +        {
      +          "type": "string"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ]
      +    },
      +    "resumeBuildId": {
      +      "type": "number"
      +    },
      +    "template": {
      +      "type": "string"
      +    },
      +    "url": {
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "resumeBuildId",
      +    "template",
      +    "url",
      +    "publicUrl"
      +  ],
      +  "type": "object"
      +}
  4. First observedv1.3.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only give the generic safety profile (readOnly false, non-destructive, non-idempotent, openWorld). The description adds material traits they don't: a paid-plan requirement, the private-by-default posture, the preview-vs-creation distinction when resume_text is omitted, and the inherent limitation that it will not split text into experience/education/skills sections. These are exactly the behavioral facts an agent needs before invoking it.

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?

Core purpose is front-loaded and every sentence carries an actionable rule (section limitation, default privacy, plan gate, sibling routing, no-input behavior). It runs long and the optionality of resume_text is effectively stated twice, but nothing is padding in the way of restating the title.

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 zero-required-parameter mutation tool with an output schema, the description covers the gaps structured fields cannot: prerequisite plan, privacy default, the empty-input fallback return path, and honest scoping of what the tool does not do. An agent has everything needed to decide whether to call it and what to expect.

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 the baseline is 3, and the description stays mostly within what the schema already states for template and make_public. It does add one genuinely new constraint not present in the schema – resume_text is funneled into a summary section capped at 2,000 characters – which meaningfully shapes how an agent should call the tool.

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 resource ('Create an editable resume draft') and immediately clarifies the tool's dual nature, resolving the tension between the build_pdf name and the draft-creation behavior. It also distinguishes itself from a same-domain sibling by name (aiapplyd_optimize_resume), so an agent can route correctly without opening a schema.

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?

Gives explicit when-not ('Do not use it to rewrite a resume; use aiapplyd_optimize_resume'), a conditional gate for make_public ('only if the user explicitly asks to share'), a plan prerequisite (Hired in 30+), and the no-input branch behavior. Alternatives and selection conditions are stated outright rather than implied.

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