Skip to main content
Glama
Sign In
Maestro Career Studio

Maestro Career Studio

Official
by seinun-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Stage PDF for Upload

prepare_application_pdf_upload
Idempotent

Stages a disposable copy of an application's rendered PDF, rendering it first if needed, and returns an absolute upload path for Playwright's file chooser.

Instructions

Stage a disposable copy of an application's canonical rendered PDF for direct Playwright upload: its tailored resume by default, or its cover letter (document). If the PDF has not been rendered, render it and retry once. Writes atomically under $MAESTRO_CS_UPLOAD_DIR/<application_id>/, defaulting to the repository's .playwright-mcp/uploads directory (pair Playwright --output-dir with the parent .playwright-mcp tree). Returns upload_path, an absolute path usable directly by Playwright's file chooser. The staged copy is the only location intended for browser file uploads; the canonical server artifact (under applications/artifact_dir) is preserved and is not an upload source. Also returns filename/path integrity and PDF lint metadata. This preparation tool does not authorize or submit an application.

Input Schema

NameRequiredDescriptionDefault
documentNo"resume" (default): the tailored resume's PDF. "cover_letter": the PDF of the cover letter stored for the application (store_cover_letter or generate_cover_letter), rendered first when it has none, staged in the same folder under its own file name, so the two copies sit side by side. With no cover letter stored the call is refused and nothing is staged.resume
application_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.12.0
    • addedInput schema / properties / document
      Added value: +{
+  "default": "resume",
+  "description": "\"resume\" (default): the tailored resume's PDF. \"cover_letter\": the PDF of the cover letter stored for the application (store_cover_letter or generate_cover_letter), rendered first when it has none, staged in the same folder under its own file name, so the two copies sit side by side. With no cover letter stored the call is refused and nothing is staged.",
+  "enum": [
+    "resume",
+    "cover_letter"
+  ],
+  "title": "Document",
+  "type": "string"
+}
  2. First observedv0.11.1

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare non-readOnly, idempotent, non-destructive, so the safety profile is covered; the description adds genuinely new behavior — atomic writes, render-then-retry-once, refusal when no cover letter exists, and preservation of the canonical artifact. It stops short of describing failure modes beyond the retry or the size/shape of the lint metadata, so not a full 5.

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-loaded with the core action and its default, then the pathing caveat, the return value, and the non-authorization disclaimer in descending order of importance. The Playwright --output-dir parenthetical is dense but functional; a slightly tighter phrasing would reach 5.

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?

With no output schema, the description carries the return contract itself (upload_path as an absolute Playwright-usable path, plus filename/path integrity and PDF lint metadata), and it covers the env-var default location. An agent has everything needed to invoke it and consume the result without guessing.

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 only 50%, but the description compensates for the undocumented half by explaining the default document value, the cover-letter branch, and the side-by-side staging behavior. The required application_id is left unexplained, though its meaning is evident from the path template shown in the description.

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 clause names a specific verb and resource — stage a disposable copy of an application's canonical rendered PDF — for a named consumer (Playwright file upload), and explicitly scopes the default (tailored resume) versus the alternative (cover letter). It is clearly distinguishable from sibling render_pdf/get_rendered_pdf, which produce or fetch the canonical artifact rather than an upload-ready staging copy.

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?

States when to use it (browser file uploads), which of the two documents to request, and the environment/path pairing needed to make the result usable. It also draws an explicit boundary: the staged copy is the only upload source, the canonical artifact under applications/artifact_dir is not, and this tool does not authorize or submit — routing the agent away from mark_submitted.

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