Skip to main content
Glama

Export an interview prep file

export_prep_pack

Builds the full interview plan (as prepare_interview_plan) as a Word file (.docx): the questions by interview stage with the points a strong answer includes, the requirement map and the gaps, and the answer texts the person kept with save_practice. Returns a download link that works once and expires after 10 minutes; the file is built in memory and not kept. Contact details are removed before the check. Requires sign-in with a PM Career Desk account that has an Interview Coach Pass.

Input Schema

NameRequiredDescriptionDefault
roleNoOptional. One of project-manager, program-manager, technical-program-manager, product-manager, scrum-master, pmo, it-manager, business-analyst, delivery-manager; a title as written (for example Senior Program Manager) is also read. Empty when not sure.
companyNoOptional. The employer's name as written in the posting.
job_postingNoThe full text of the job posting, as the person gave it. Optional; with it the result adds the requirements, the gaps and questions about them.
resume_textYesThe resume as plain text, copied in full from what the person pasted or from the text of the file they attached. At least the summary and the experience section.
resume_outlineNoOptional structure of the resume: roles with title, company, dates and bullets; summary; skills; certifications; education. Every line must appear word for word in resume_text; lines that do not are left out and counted in the result. Without it the plain text is read.
job_requirementsNoOptional. The requirement lines of the job posting, each word for word from job_posting; lines that are not are left out and counted in the result. Without them the requirements are read from job_posting.
include_saved_answersNoFalse leaves the kept practice answers out of the file.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing the one-time download link, the 10-minute expiry, in-memory construction with no retained file, contact-detail scrubbing before the check, and the account/Pass requirement. These are exactly the operational traits an agent cannot infer from readOnlyHint=false and destructiveHint=false.

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 what is produced, then the return value, then the constraints. Two dense sentences with little waste, though the parenthetical and the list of contents make the first sentence long enough to slow scanning.

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 still explains the return value (single-use expiring download link) and the artifact contents. Combined with the auth prerequisite and the seven optional/required parameters documented in the schema, an agent has everything needed to invoke it correctly.

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 description coverage is 100%, so the schema already documents role, company, job_posting, job_requirements and resume_outline in detail. The description adds thematic context (the requirement map and gaps come from the posting; the answer texts come from save_practice) but does not add format or syntax detail beyond the schema, so the baseline of 3 applies.

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 precise verb and artifact: builds the full interview plan as a Word .docx and returns a download link. It explicitly anchors the content to prepare_interview_plan and to save_practice answers, so an agent can distinguish it from the sibling that only prepares the plan.

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?

Usage context is clear: this is the file-export counterpart of prepare_interview_plan, and it requires an Interview Coach Pass, which is a genuine gating condition. What is missing is an explicit statement of when to choose this over prepare_interview_plan (view plan in chat vs. download a document).

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