What can you do with this server?

The mcp-overleaf-server automates tailoring LaTeX résumés and cover letters to job descriptions using your MCP client's AI model, with truthfulness enforcement, PDF compilation, and application tracking. * Tailoring & Compilation: Analyze job descriptions, select and rewrite bullets from your master cv.md, inject into LaTeX template, and compile PDFs. Supports both résumés and cover letters, auto-detecting LaTeX file types. * Truthfulness Enforcement: Every bullet must cite a source ID from the master CV; unverifiable numbers or skills are flagged and unknown IDs cause hard failures. * Batch Processing: Handle up to 10 jobs at once, clustering similar roles to reuse content and minimize LLM calls, with cross-session caching. * ATS Reporting: Generate keyword coverage reports, distinguishing skills addable from your master CV vs. absent entirely. * Application Tracking: Auto-log applications to applications.csv with intelligent upserting; manually list, add, or update records. * Master CV Management: View parsed master CV with stable IDs for transparent content sourcing. * Overleaf Integration: Optionally sync with Overleaf via Git (requires paid access) to pull templates or push compiled documents. * Customizable Output: Integrates with existing LaTeX templates, preserving custom macros and typography.

Which integrations are available for this server?

Allows syncing templates from Overleaf and pushing compiled PDFs back to an Overleaf project using git.

How do I use mcp-overleaf-server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-overleaf-server Tailor my resume for the software engineer role at Stripe." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

mcp-overleaf-server

by abhi-ramtel

Overview Schema Related Servers Score Discussions

TypeScript

Local

mcp-overleaf-server

An MCP server that tailors your LaTeX résumé and cover letter to any job description — injecting truthfully-selected content from a master cv.md into your own LaTeX document, compiling the PDF, and logging the application automatically. Paste a job description into any MCP client (Claude Desktop, Cursor, VS Code, Windsurf) and get back an ATS-optimized, one-page PDF.

Truthfulness is enforced by code, not just prompts. The server refuses to compile any bullet that can't be traced back to your master CV, and flags any new number or skill for review.

How it works

The reasoning (analyze the JD, rank experience, rewrite bullets) is done by your MCP client's model — no API key, no extra LLM cost. The server is a set of deterministic tools plus orchestrating prompts:

/tailor_resume "<paste JD>"
   │
   ├─ prepare_tailoring(JD)    → master CV (with ids) + JD keyword signals + rules + schema
   │      … your model reasons here → emits TailoredContent JSON …
   │         (only reorders/rewrites/shortens existing bullets; cites source ids)
   └─ render_and_compile(json + coverLetter)
          inject → validate → anti-fabrication check → compile
          → Company_Position.pdf + Company_Position_CoverLetter.pdf
          → auto-logged to output/applications.csv

Related MCP server: Resume Generator MCP Server

Requirements

Node.js ≥ 20 (developed on 26)
A LaTeX toolchain — latexmk + pdflatex (install MacTeX / TeX Live). Check with latexmk --version.
An Overleaf git token — optional, only for the Overleaf sync/push tools. Overleaf git access is a paid feature; everything else works without it.

Setup

npm install && cp .env.example .env && npm run build

Put your master CV at cv.md (see cv.example.md for the structure — ## Summary, ## Experience, ## Projects, ## Education, ## Skills), and drop your polished résumé at templates/main.tex. Both are gitignored — they never get published.

.env:

OL_GIT_AUTHENTICATION_TOKEN=olp_xxxxxxxxxxxx    # optional
OVERLEAF_PROJECT_URL=https://www.overleaf.com/project/xxxx   # optional
CV_MASTER_PATH=./cv.md
CAREER_OUTPUT_DIR=./output
LATEX_ENGINE=latexmk

Connect to an MCP client

All clients below launch the same process — node /ABSOLUTE/PATH/mcp-overleaf-server/dist/index.js — they just each want that command in their own config file/format. The server reads .env from its own directory, so secrets never need to go in any client config. Always use the absolute path (not ~ or a relative path) and fully restart the client after editing — MCP tool lists are only fetched at connection time.

Claude Desktop / Cursor / VS Code / Windsurf

Add to claude_desktop_config.json (or the equivalent MCP settings in Cursor/VS Code/Windsurf — same shape):

{
  "mcpServers": {
    "overleaf-resume": {
      "command": "node",
      "args": ["/ABSOLUTE/PATH/mcp-overleaf-server/dist/index.js"]
    }
  }
}

See examples/claude_desktop_config.json.

Codex CLI

Add to ~/.codex/config.toml:

[mcp_servers.overleaf-resume]
command = "node"
args = ["/ABSOLUTE/PATH/mcp-overleaf-server/dist/index.js"]

Or skip the file entirely:

codex mcp add overleaf-resume -- node /ABSOLUTE/PATH/mcp-overleaf-server/dist/index.js

Verify with codex mcp list. See examples/codex_config.toml.

Gemini CLI

Add to ~/.gemini/settings.json (global) — a project-level .gemini/settings.json works too, but this tool isn't tied to any one repo:

{
  "mcpServers": {
    "overleaf-resume": {
      "command": "node",
      "args": ["/ABSOLUTE/PATH/mcp-overleaf-server/dist/index.js"]
    }
  }
}

See examples/gemini_settings.json. Gemini CLI expands $VAR references inside a server's env block if you ever need to inject a secret that way — not needed here since .env covers it.

Ollama

Ollama itself is a model runtime, not an MCP client — it has no built-in concept of "MCP servers" to connect to. To use this server with a local Ollama model, put an MCP-aware layer in between:

mcp-client-for-ollama (ollmcp) — a terminal client that connects a local Ollama model to one or more MCP servers, this one included.
ollama-mcp-bridge — exposes MCP tools through Ollama's API for other tooling to consume.

Either way, the command you register is the same node /ABSOLUTE/PATH/mcp-overleaf-server/dist/index.js — consult that project's docs for exactly where its config lives.

Usage

First: how to invoke a prompt in your client

The two prompts (tailor_resume, tailor_multiple_jobs) surface differently depending on the client:

Client	How to invoke
Claude Code	Type `/mcp` and pick from the list, or type the namespaced name: `/mcp__overleaf-resume__tailor_resume`
Claude Desktop	The ➕ button next to the message box — not a typed slash command
Codex / Gemini CLI / Cursor	Prompt support varies. If you don't see them, just ask in plain English (below) — the tools work regardless

You never actually need the prompts. They're convenience wrappers. Asking in plain English works everywhere.

Copy-paste prompt for Codex

After connecting the server and restarting Codex, paste the following into Codex and replace the bracketed fields. Codex will use the connected overleaf-resume tools to do the work:

Please tailor my résumé for the job below and create a matching cover letter when asked i.e. the coverletter flag is set to true.

Use my master cv.md and my existing LaTeX template. First read the tailoring brief,
then select, reorder, and rewrite only accomplishments that are supported by my CV.
Do not invent experience, skills, employers, projects, or numbers. Start with four
relevant experience entries and three relevant projects when my CV supports them, with
three distinct sourced bullets for every selected entry that has that much evidence.
Do not cut this baseline merely because it appears likely to fit on one page. Preserve
the template's design, and only shorten content after the compiled PDF is actually over
one page. If it reports that the page is under-filled, add more relevant sourced content
and compile it again. The final text should reach close to the bottom of the page, like
my existing template; do not leave a large empty lower third.

Compile the résumé and cover letter to PDF, save them with the company and role in the
filename, and log this application in the tracker. Before you finish, tell me the PDF
paths, ATS coverage, page count, and any provenance or formatting warnings.

Company: [company name]
Role: [job title]
Job URL: [optional URL]

Full job description:
[paste the complete job posting text here]

To make only a résumé, replace “and create a matching cover letter” with “and do not create a cover letter.”

Compact job-card input for Codex

You can also paste a job card by itself. Codex treats these fields as instructions, including the boolean cover-letter flag. Keep false unquoted — "false" is text, not a JSON boolean.

{
  "CompanyName": "Example Company",
  "JobDescription": "Paste the full job posting here.",
  "JobTitle": "Software Engineer",
  "JobLink": "https://example.com/jobs/123",
  "CoverLetter": false,
  "Application Question": "Why are you interested in this role?"
}

CoverLetter: false means résumé only: Codex must not generate or compile a cover letter. Application Question is answered in chat after the résumé is generated; it is never added to the PDF. CompanyName, JobTitle, and JobLink are accepted as aliases for company, position, and job URL.

IMPORTANT

Paste the full posting text, not a URL. Most job boards (Ashby, Greenhouse, Lever) render postings with JavaScript, so a link fetches nothing. An empty or stub jobDescription is now rejected outright — tailoring, ATS scoring, and the cover letter all depend on that text.

One job

/mcp__overleaf-resume__tailor_resume

Argument	Required	Notes
`jobDescription`	yes	The full posting text (≥100 chars)
`company` / `position`	recommended	Used for filenames and the tracker row
`jobUrl`	optional	Recorded in the tracker
`questions`	optional	Portal questions, one per line — answered in chat
`coverLetter`	optional	`"false"` to skip the letter (default: generate it)
`template`	optional	`"resume"` (default), or `"cv"` when you have supplied `templates/cv.tex`

Produces: Company_Position.pdf and Company_Position_CoverLetter.pdf, plus one tracker row — all from a single render_and_compile call. A separate CV is only produced when you explicitly configure your own templates/cv.tex and pass alsoCv: true.

Many jobs at once (up to 30)

/jobs

Pick how many jobs you're doing, and you get that many entry cards in the chat — company, role, URL, job description, application questions, cover letter on or off. Fill them in, hit Tailor them, and the batch runs. Leave company or role blank and they're read off the posting.

/jobs is a project skill (.claude/skills/jobs/) and needs a client that renders in-chat forms — the Claude Code desktop app does. Everywhere else, use the MCP prompt:

/mcp__overleaf-resume__tailor_multiple_jobs

Pass jobs as ----separated blocks. Company:, Position:, Job URL:, and Question: lines are parsed as fields; everything else is the description:

Company: Nuro
Position: Software Engineer
Question: Why do you want to work here?
<paste the full JD>
---
Company: Waymo
Position: Backend Engineer
<paste the full JD>

Or pass only a location argument pointing to a readable local file, attachment, or URL. The host model reads it, infers missing company/role/URL fields, and then follows the same batch flow. This is useful for a saved jobs list:

LOCATION: /absolute/path/to/jobs.txt

The batch prompt prioritizes polished, standard one-page layouts: it uses four relevant experience entries when the master CV has them, gives the most relevant projects fuller sourced evidence, and retains master-CV skill labels. It fills a page with content rather than shrinking the template's professional type scale or margins.

This is the credit-efficient path. batch_plan does three things before any content is written: it skips jobs you've already done, clusters the rest by keyword similarity (checking a cross-session cache), and splits the remaining work into chunks of three — one batch_render call each, so no single call can run long enough to time out. That's what lets a batch go past ten jobs.

Batch plan — 8 job(s): 5 to render in 2 call(s) of up to 3, 3 skipped. 3 reasoning pass(es) needed, 2 saved by reuse.

SKIPPED — no work needed, do not render these:
  ⏭  #5  Nuro — Software Engineer: same company+position as job #0 in this list.
  ⏭  #6  Stripe — Backend Engineer: job description is 8 chars — paste the full posting.
  ⏭  #7  (no company) — Backend Engineer: missing company — read it off the posting.

── Chunk 1 of 2 — batch_render with these 3 job(s):
   [0]  Nuro — Software Engineer     [resume]  →  GENERATE  ← write content for this one
   [1]  Waymo — Backend Engineer     [resume]  →  reuseFrom: 0 (job [0] in this same call, similarity 0.78)
   [2]  Figma — Frontend Engineer    [resume]  →  GENERATE  ← write content for this one

── Chunk 2 of 2 — batch_render with these 2 job(s):
   [0]  Linear — Frontend Engineer   [resume]  →  reuseFrom: "figma|frontend engineer" (similarity 0.81)
   [1]  OpenAI — ML Engineer         [resume]  →  GENERATE  ← write content for this one

Tune with threshold (0–1, default 0.6) — raise it toward 0.9 to force fresh reasoning per job. chunkSize overrides the three-per-call default (max 10).

Reuse means an identical résumé body, not a re-tailored one. For a role you care about, run it single-job or raise the threshold.

Re-running is safe

A job already in output/applications.csv whose PDF is still on disk is skipped, not rebuilt — by both batch_plan and batch_render. So:

Submitting the same list twice is a no-op instead of an error or a pile of overwritten files.
A batch that died halfway through can be resumed by re-sending the whole list; only the missing jobs get built.
Delete the row (or the PDF), or pass force: true, to deliberately redo one. Single-job render_and_compile always regenerates — it's the "redo this one" path.

Other things that used to break a run and now just get reported per job: duplicate entries in one list, a blank company or role, a stub job description, a reuse pointer whose target failed, and a cache entry that vanished between planning and rendering. One bad job never fails the call.

Calling tools directly

You can ask for any individual tool by name instead of running a whole prompt:

You want to…	Say something like
See your parsed CV and its IDs	"Show me my master CV" → `get_master_cv`
Score an existing résumé against a JD	"ATS-check this resume against this posting" → `ats_report`
Review what you've applied to	"List my applications" → `list_applications`
Add a row manually	"Mark the Nuro application as applied" → `update_tracker`
Write only a cover letter	"Write a cover letter for X" → `render_cover_letter`
Pull your Overleaf templates	"Sync my Overleaf project" → `overleaf_sync`

After it runs

Everything lands in output/:

open output/

Company_Position.pdf — the one-page résumé
Company_Position_CoverLetter.pdf — the letter
applications.csv — the tracker (opens in Excel / Google Sheets)
.tailoring-cache.json — reuse cache; delete it to force fresh reasoning

Read the tool's response before sending anything out. It reports ATS coverage, which missing keywords are truthfully addable vs. absent from your CV, any provenance warnings (a number or skill it couldn't trace to cv.md), and a warning if a document ran past one page.

Troubleshooting

Symptom	Cause
"No batch processing tool available" / tools missing	The client cached an old tool list — fully quit and reopen it (⌘Q, not just closing the window)
No cover letter produced	The model didn't pass `coverLetter`. Usually caused by an empty `jobDescription` — paste the real posting and re-run
"job description is empty or too short"	Working as intended — paste the posting text, not a URL
A job was skipped as "already generated"	It's in `applications.csv` with its PDF on disk. Pass `force: true`, or delete the row, to rebuild it
A batch stalls or the client drops the call	Too many jobs in one `batch_render`. Follow `batch_plan`'s chunks — three per call
"No cached content for key …"	The reuse cache was cleared between planning and rendering. Re-run `batch_plan` for the remaining jobs
Overleaf sync says unavailable	Overleaf git access is a paid feature. Not an error; local templates are used instead
Compile fails	Check `latexmk --version`; install MacTeX / TeX Live

Tools

Tool	What it does
`prepare_tailoring`	Returns the brief: master CV with stable ids + JD keyword signals + rules + output schema
`render_and_compile`	Inject → validate → anti-fabrication check → compile → save `Company_Position.pdf`; also renders the cover letter and auto-logs the application
`render_cover_letter`	Standalone one-page cover letter (usually unnecessary — pass `coverLetter` to `render_and_compile` instead)
`batch_plan`	Up to 30 jobs: skips ones already done, clusters the rest, and chunks them 3 per render call
`batch_render`	Renders, compiles, writes letters, and logs one chunk; skips jobs already in the tracker
`get_master_cv`	The parsed master CV with the ids used for tailoring
`ats_report`	Keyword coverage vs. a JD; splits gaps into addable (in your CV) vs absent
`update_tracker` / `list_applications`	Manual tracker access (logging is automatic)
`overleaf_sync` / `overleaf_commit_push`	Pull templates from / push results back to Overleaf

Your own LaTeX document

Point the server at templates/main.tex and it auto-detects which kind of file it is:

A finished résumé (custom macros like \roleheading / \bul, no placeholders) → rewrites only the Summary / Experience / Projects / Skills section bodies. Your preamble, fonts, colors, spacing, and Education section are preserved byte-for-byte.
A {{PLACEHOLDER}} template → the placeholder renderer fills each token.

Project links

Write a project heading in cv.md as a markdown link and it stays hyperlinked in the compiled PDF:

**[CarbonProxy](https://devpost.com/software/carbonproxy)** - Python, FastAPI, SQLite

→ \projheading{\textbf{\href{...}{CarbonProxy}} $|$ \emph{...}}{Feb 2026}

The tracker sheet

output/applications.csv opens in Excel / Google Sheets and is git-diffable. Columns: Date Applied · Company · Position · Job Link · ATS % · Resume File · Git Link · JD Summary · Status · Notes.

Every render auto-logs, upserting on company+position — regenerating updates the row instead of duplicating.

Architecture & design decisions

TypeScript, not Python. The whole system is I/O orchestration (git, fs, subprocess, template injection). Building on the mature MCP TypeScript SDK avoided a rewrite and a second toolchain.
Host-model reasoning, not a server-side LLM. The MCP client already has a capable model; calling an API server-side would need a key, double the cost, and duplicate the model. The server hands the model a structured brief and renders the JSON it returns. No key required.
Template injection, never LLM-generated LaTeX. The renderer is the only component that emits LaTeX, and it escapes every field. Your macros and typography survive exactly.
Anti-fabrication by construction. Every source bullet gets a stable id (EXP1.2). The model must cite one per bullet; unknown ids are a hard failure, and new numbers / off-CV skills become warnings. Cover letters get a prose-tuned variant that flags unverifiable figures. See src/core/schema.ts.
Reuse over regeneration. Deterministic Jaccard similarity over JD keywords decides what can be reused — no model call is needed to decide what to skip. See src/core/batch.ts.
Idempotent batches, chunked work. The tracker is the record of what's done, so re-running a list rebuilds nothing and a half-finished batch resumes by re-submitting it. Work is handed back in groups of three rather than one long call, because a call long enough to time out is what actually loses a batch — and chunking is what lets one run exceed the ten-job per-call ceiling.
Graceful Overleaf degradation. No git access (a paid feature) returns a normal "unavailable" result, not an error, and the failure is cached so the token is never re-spent.
CSV tracker, not a database. Excel-openable, git-friendly, zero infrastructure.

Project structure

src/
  index.ts              MCP bootstrap (tools + prompts, stdio)
  config.ts             env + resolved paths
  tools.ts              the MCP tools
  prompts.ts            tailor_resume + tailor_multiple_jobs
  core/
    cvParser.ts         cv.md → structured model with stable ids
    schema.ts           TailoredContent + CoverLetterContent (zod) + provenance checks
    latexRenderer.ts    structured content → LaTeX (escaping, macros, \href)
    documentInjector.ts rewrites section bodies of YOUR finished .tex
    latexValidate.ts    pre-compile structural checks
    latexCompile.ts     latexmk / pdflatex → PDF
    coverLetter.ts      one-page letter rendering
    batch.ts            similarity, clustering, cross-session cache, batch runner
    atsNormalize.ts     Unicode → ATS-safe ASCII
    keywords.ts         JD keyword extraction, coverage, gap analysis
    tracker.ts          CSV application sheet
    overleafGit.ts      project-URL → authed git; clone/pull/branch/commit/push
    brief.ts            the tailoring brief prepare_tailoring returns
    pipeline.ts         compose layer (render→validate→compile→save→log)
templates/              main.tex (yours, gitignored) · resume-template.tex
                        cover-letter-template.tex · AUTHORING.md
.claude/skills/jobs/    /jobs — the in-chat multi-job entry form
test/                   43 unit + integration tests (incl. real PDF compiles)

Development

npm test         # 43 tests, including real latexmk compiles
npm run typecheck
npm run build

Roadmap

Embedding-based bullet ranking · multiple role templates (SWE/AI-ML/Security/Quant) · preserving bold metrics through injection · optional server-side provider for a fully autonomous single call.

License

MIT. Résumé template derived from the sb2nov / Gabriel Sison template (MIT).

Available Tools

11 tools

ats_reportATS keyword reportB

Score how well a resume covers a job description's keywords, and split the gap into truthfully addable (already in your CV) vs. absent. Provide resumeText or a texPath.

ParametersJSON Schema

Name	Required	Description
`texPath`	No	Path to a rendered .tex (converted to text)
`resumeText`	No	Plain resume text (alternative to texPath)
`jobDescription`	Yes

TDQS

B3.3/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses that the tool scores and splits gaps, which implies a read-only analysis. However, it does not mention any side effects, authentication, or rate limits, leaving some behavioral gaps.

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 two sentences: the first covers purpose and output, the second specifies inputs. Every word adds value with no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description lacks detail on output format (e.g., numerical score, categories). Without an output schema, this is a significant gap. It also does not mention that jobDescription is required or that resumeText and texPath are alternatives, reducing completeness for an agent.

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?

The description clarifies that only one of resumeText or texPath should be provided, adding meaning beyond the schema. The jobDescription parameter is implied but not explicitly explained. With 67% schema coverage, the description compensates adequately but could describe jobDescription semantics.

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 clearly states the tool scores resume keyword coverage against a job description and categorizes gaps. The verb 'score' and resource 'resume-job description keyword match' are specific. While it doesn't explicitly contrast with sibling tools, the purpose is distinct enough from related tools like get_master_cv or prepare_tailoring.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or common use cases, which limits the agent's ability to choose correctly among siblings.

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

batch_planPlan a multi-job batch (saves reasoning passes)A

Plan up to 10 jobs at once. Deterministically clusters jobs by keyword similarity and checks a cross-session cache, then tells you EXACTLY which jobs need fresh TailoredContent. Similar roles share one reasoning pass — write content only for the listed indices, then call batch_render once. Call this BEFORE writing any content for a multi-job request.

ParametersJSON Schema

Name	Required	Description
`jobs`	Yes
`useCache`	No	Reuse content cached from previous sessions (default true)
`threshold`	No	Similarity 0-1 above which jobs share content (default 0.65)

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations, the description bears full burden. It discloses clustering, caching, and shared reasoning behavior, but does not mention the output format, side effects, or permissions needed. The agent would benefit from knowing what the tool returns and whether it is purely read-only.

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 concise, with no redundant information. It front-loads the main purpose and function, then provides actionable steps for usage. Every sentence adds value.

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?

Given no output schema or annotations, the description covers purpose, usage order, clustering logic, caching, and hints at output (which jobs need content). It is missing explicit output structure and error/edge case handling, but is otherwise complete for a planning tool.

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 67% (jobs parameter lacks description). The description compensates by explaining that jobs are clustered by keyword similarity and that roles share reasoning passes, adding meaning beyond the schema. The other parameters (useCache, threshold) are already described in the schema.

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's purpose: planning up to 10 jobs by clustering similar roles and checking a cache, then indicating which jobs need fresh content. It distinguishes itself from siblings like 'batch_render' by specifying that this tool is for planning before writing content.

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?

The description explicitly instructs to call this tool before writing content for multi-job requests, and mentions that after planning one should call 'batch_render'. It implies it is for multiple jobs but does not explicitly exclude single-job scenarios or mention alternatives like 'prepare_tailoring'.

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

batch_renderRender, compile & log a whole batchA

Render, compile, auto-log, and cache every job in one call — no per-job round trip. Supply content only for jobs batch_plan marked GENERATE; for the rest pass reuseFrom (the batch index or cache key from the plan) and the server resolves the content itself. Every job is automatically written to the application tracker.

ParametersJSON Schema

Name	Required	Description	Default
`jobs`	Yes

TDQS

A4/5.0

Behavior3/5

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

The description discloses side effects (auto-logging to tracker, caching) and the two operational modes, which adds value beyond the schema. However, with no annotations, it lacks details on idempotency, error behavior, and permissions required.

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 description is a focused paragraph that front-loads the main action and includes necessary technical details without excessive verbosity. It could be slightly more concise but is well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the core batch behavior and auto-logging but omits mention of optional cover letter support and template options (resume/cv). Given the complex input schema and lack of output schema, more details would improve completeness.

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?

The description explains the conditional logic between 'content' and 'reuseFrom' parameters, clarifying that 'content' is only needed for GENERATE jobs and for others 'reuseFrom' is used to resolve content automatically. This adds significant guidance beyond the schema descriptions.

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 renders, compiles, auto-logs, and caches a batch of jobs in one call. It distinguishes from sibling tools like 'batch_plan' (planning) and 'render_and_compile' (per-job) by emphasizing no per-job round trip and referencing the batch 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?

The description implies that this tool should be used after 'batch_plan' and instead of calling 'render_and_compile' for each job. It explicitly mentions the two modes (GENERATE vs reuse) but does not explicitly state prerequisites or when to avoid using it.

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

get_master_cvGet master CVA

Return the parsed master CV (cv.md) with the stable ids used for tailoring.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It discloses the return value (parsed CV with stable IDs) but does not mention side effects, auth requirements, or format details. Since it's a read operation with zero parameters, basic behavior is clear but lacks depth.

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?

Single sentence that conveys the entire purpose without any superfluous words. Front-loads the action and key details.

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?

Given zero parameters and no output schema, the description sufficiently explains what the tool returns. Could be improved by specifying the output format or linking to related tools, but is adequate for the simplicity.

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?

No parameters exist, schema coverage is 100%. Baseline for 0 parameters is 4, and the description adds no parameter information as none is needed.

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?

Clearly states the tool returns a parsed master CV (cv.md) with stable IDs for tailoring. The verb 'Return' is specific, and the resource and scope are precisely defined, distinguishing it from sibling tools like prepare_tailoring or render_and_compile.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage before tailoring by mentioning 'stable ids used for tailoring', but no explicit when-to-use or alternatives are given. Sibling tools exist but no guidance on selection.

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

list_applicationsList tracked applicationsA

Return all rows from the application tracker sheet.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly indicates a read operation ('return') but omits details like potential performance impact, whether the data is fresh, or if authentication is needed. The simplicity of a no-parameter list-all makes this acceptable.

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 a single sentence of nine words, front-loaded with the core action, and contains no wasted content. It is highly efficient for its purpose.

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?

For a parameterless read tool, the description effectively states what it returns. However, it could briefly mention the expected row structure or field names, especially since no output schema is provided. Still, it is largely complete.

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?

There are no parameters, and the input schema is empty. The description does not need to add parameter details. The baseline for 0 parameters is 4, and the description meets it without requiring additional explanation.

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 returns all rows from the application tracker sheet, matching the verb 'list' and specifying the data source. It distinguishes from siblings like 'update_tracker' and 'ats_report' by focusing on a full read-only list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving the complete list of tracked applications, but does not explicitly state when to use it over alternatives or provide any exclusions. For a simple read tool, this is adequate but not exemplary.

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

overleaf_commit_pushCommit (and optionally push) to OverleafA

Commit changes in the synced Overleaf repo, optionally to a branch, and push back to Overleaf. Pushing publishes to your Overleaf project — set push=true only when you intend that.

ParametersJSON Schema

Name	Required	Description
`push`	No	Push to Overleaf (default false)
`files`	No	Specific files to stage (default: all changes)
`branch`	No	Create/switch to this branch before committing
`message`	Yes	Commit message
`project`	No

TDQS

A3.9/5.0

Behavior3/5

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

No annotations provided, so description carries the burden. It discloses that push publishes, but lacks details on destructive potential, rollback, or permission requirements.

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?

Two sentences, front-loaded with clear action, minimal waste. Every sentence serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 5 parameters and no output schema or annotations, the description is brief. It omits details on commit flow, error handling, and the project parameter.

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 high (80%), and the description does not add extra meaning beyond the schema descriptions. The 'project' parameter lacks description in both schema and 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 title and description clearly state the tool commits changes and optionally pushes to Overleaf. It distinguishes from siblings like overleaf_sync by focusing on commit and push actions.

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?

The description provides guidance on when to use push ('set push=true only when you intend that'), but does not explicitly mention alternatives or when not to use the tool.

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

overleaf_syncSync Overleaf projectA

Optional. Clone (or pull) your Overleaf project via its git repo and list the .tex files. Overleaf git access is a premium feature — if it isn't available this returns a normal 'unavailable' result (NOT an error) and you should simply continue with the local templates. The failure is cached so later runs skip the network call entirely.

ParametersJSON Schema

Name	Required	Description	Default
`force`	No	Re-check even if a previous attempt was cached as unavailable
`project`	No	Overleaf project URL or 24-char id

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses that Overleaf git access is a premium feature, that failure is cached, and that a normal 'unavailable' result is returned instead of an error. However, it does not warn about potential side effects like overwriting local files during pull.

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 description is two sentences, but the first word 'Optional.' is somewhat ambiguous and could be removed or clarified. Overall, it is fairly concise and front-loaded with the main action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the main purpose and behavior regarding availability and caching, but it lacks details on the return value format (e.g., what 'list the .tex files' means in terms of output). Given no output schema, more context would be beneficial.

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 both parameters are already described in the schema. The description adds no new information beyond what the schema provides (e.g., 'force' and 'project' descriptions are identical). Baseline 3 is appropriate.

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's action: 'Clone (or pull) your Overleaf project via its git repo and list the .tex files.' It uses a specific verb (sync) and resource (Overleaf project), and distinguishes it from the sibling tool overleaf_commit_push.

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?

The description explains when to use the tool and provides guidance: if the feature is unavailable, it returns an 'unavailable' result (not an error) and the agent should continue with local templates. However, it does not explicitly compare to alternatives like overleaf_commit_push.

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

prepare_tailoringPrepare tailoring briefB

Return everything YOU (the host model) need to tailor the resume/CV to a job description: the master CV with ids, deterministic JD keyword signals, the strict anti-fabrication rules, and the exact output schema. After reasoning, call render_and_compile with the TailoredContent JSON.

ParametersJSON Schema

Name	Required	Description
`jobUrl`	No
`company`	No
`position`	No
`template`	No	Which document to produce (default resume)
`jobDescription`	Yes	The full pasted job description

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations provided, the description must fully disclose behavior. It lists the output components but does not specify whether the tool is read-only, requires any permissions, or has side effects. There is no mention of error conditions or the exact format of returned data beyond general names, leaving ambiguity about what the agent should expect.

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 description is short (two sentences) and front-loads the key output components. However, the first sentence is somewhat meta ('Return everything YOU (the host model) need'), which is slightly indirect but still functional. No extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 5 parameters, no output schema, and no annotations, the description is incomplete. It mentions output components like 'deterministic JD keyword signals' and 'strict anti-fabrication rules' without explaining their structure or how the agent should use them. The reference to 'TailoredContent JSON' is vague, and the agent may need more detail to correctly produce the required output for render_and_compile.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 5 parameters, but only 40% have descriptions (jobDescription and template). The tool description does not add any additional meaning or usage hints for the parameters like jobUrl, company, or position. It fails to compensate for the low schema coverage, leaving the agent to infer their roles from context.

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's purpose: to provide the host model with everything needed to tailor a resume/CV to a job description. It specifies the resource ('tailoring brief') and the verb ('return'), and the inclusion of specific components (master CV, JD signals, rules, schema) distinguishes it from siblings like 'get_master_cv' and 'render_and_compile'.

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?

The description explicitly tells when to use the tool (to get all necessary information for tailoring) and what to do afterwards (call render_and_compile with TailoredContent JSON). It does not, however, mention when not to use it or provide alternatives for other scenarios, but the instruction to use this before rendering is clear.

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

render_and_compileRender & compile tailored documentA

Inject TailoredContent into the LaTeX template, verify every bullet traces to the master CV (anti-fabrication), compile to PDF, and save as _.pdf in the output dir. ALWAYS pass coverLetter too unless the user opted out — it produces the matching one-page letter in the same call. The application is auto-logged to the tracker. Returns provenance warnings and, if jobDescription is given, an ATS coverage report.

ParametersJSON Schema

Name	Required	Description
`jobUrl`	No	Job posting URL — recorded in the tracker
`company`	No
`compile`	No	Set false to only write .tex without compiling
`content`	Yes	The tailored content JSON produced from the brief
`project`	No	Overleaf project (needed only if templateFile is repo-relative)
`position`	No
`template`	No
`autoTrack`	No	Auto-log to the tracker (default true when company+position are given)
`jdSummary`	No	Short JD summary for the tracker row (auto-derived if omitted)
`headerLine`	No	Custom line under the name, e.g. 'Buffalo, NY \| Open to relocation'
`outputName`	No	Override the output filename base
`coverLetter`	No	Cover letter content — pass this to generate the résumé and letter together (recommended)
`templateFile`	No	Use a specific template .tex instead (absolute, or relative to the synced Overleaf repo)
`jobDescription`	No	Pass the JD to get an ATS coverage report

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses key behaviors: content injection, anti-fabrication verification, PDF compilation, file naming, auto-logging, and return of provenance warnings and ATS coverage report when applicable. It does not mention potential side effects like overwriting files, but the action is clear enough for safe invocation.

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 five sentences, each serving a distinct purpose: main action, cover letter guidance, auto-logging note, and return description. It is front-loaded with the core purpose, with no wasted words. Ideal balance of completeness and brevity.

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?

Given the tool's complexity (14 parameters, nested content object, no output schema), the description covers the main purpose, key behavioral nuances, and return values. It mentions provenance warnings and ATS coverage report, which are critical for understanding tool output. It could be slightly more complete by noting prerequisites (e.g., requires a tailored content from previous step), but overall it is sufficiently informative.

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?

With 79% schema description coverage, the schema already documents most parameters. The description adds behavioral context for parameters like coverLetter (recommended, generates matching letter) and jobDescription (triggers ATS report), which enhances understanding beyond the schema. The description does not repeat what the schema already covers, adding value in parameter semantics.

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 specifies the tool's function: inject TailoredContent into LaTeX, verify bullet traceability, compile to PDF, and save with a specific naming convention. It also distinguishes itself by mentioning companion cover letter generation, which is a key differentiator from sibling tools like render_cover_letter.

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?

The description explicitly instructs to 'ALWAYS pass `coverLetter` too unless the user opted out', providing strong guidance on when to use the cover letter feature. It also states the application is auto-logged, but lacks explicit comparison with sibling tools like batch_render for when to use this single-render tool versus batch alternatives.

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

render_cover_letterRender & compile a one-page cover letterA

Compile a one-page cover letter styled to match the résumé, saved as __CoverLetter.pdf. Write 3-4 tight paragraphs drawn only from the master CV: why this company/role, the most relevant proof from your experience, and a close. Never invent employers, projects, or figures — quantitative claims not found in cv.md are flagged.

ParametersJSON Schema

Name	Required	Description
`compile`	No	Set false to write .tex only
`content`	Yes	The cover letter content
`outputName`	No	Override the output filename base
`templateFile`	No	Override the letter template

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, so the description bears full responsibility. It discloses output file naming and a validation/flagging behavior for unsupported quantitative claims. However, it omits other behavioral traits such as side effects (file creation), error conditions, or resource requirements beyond the master CV.

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 description is concise at two sentences, leading with the primary purpose and output naming. The second sentence packs content rules and constraints efficiently. However, this density slightly reduces readability; separating rules into a list could improve clarity without adding length.

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?

Given the tool's complexity (4 parameters, nested object) and lack of output schema, the description covers file naming, content guardrails, and conversion control. It lacks expected output format or return value details, but the primary purpose is clear and sufficient for an AI agent to use 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 coverage is 100%, so the baseline is 3. The description adds minimal extra meaning beyond the schema: it explains the default output name pattern and rephrases the 'compile' parameter's effect. It does not elaborate on the structure or constraints of nested parameters like 'content.paragraphs' beyond what the schema already provides.

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 uses specific verbs ('compile', 'write', 'save') and a clear resource ('one-page cover letter styled to match the résumé'). It specifies the exact output filename pattern (<Company>_<Position>_CoverLetter.pdf) and scope (one page, drawn from master CV). This clearly distinguishes it from sibling tools like 'render_and_compile' by emphasizing content sourcing rules.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit content guidelines (3-4 paragraphs, no invented data) but does not explain when to prefer this tool over siblings like 'render_and_compile' or 'batch_render'. It lacks when-to-use, when-not-to-use, or alternative tool guidance.

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

update_trackerUpdate application trackerA

Add or update a row in the application tracker sheet (output/applications.csv). Upserts on company+position so regenerating doesn't duplicate.

ParametersJSON Schema

Name	Required	Description
`notes`	No
`status`	No	generated \| applied \| interview \| offer \| rejected
`company`	Yes
`gitLink`	No
`jobLink`	No
`atsScore`	No
`position`	Yes
`jdSummary`	No
`resumeFile`	No

TDQS

A3.6/5.0

Behavior3/5

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

No annotations provided, so description must cover behavioral traits. It mentions upsert behavior and file path, but lacks details on side effects, permissions, or idempotency guarantees.

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?

Two sentences, no fluff. Front-loaded with action, resource, and key behavior. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite 9 parameters and no annotations, the description is minimal. It covers core behavior but lacks details on return value, workflow integration, and parameter explanations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 11% (low). The description only adds meaning for company and position (upsert keys), leaving other parameters unexplained. Does not compensate for low coverage.

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 adds or updates a row in the application tracker CSV file, with upsert behavior on company+position. This distinguishes it from sibling tools like list_applications or get_master_cv.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives. The note about 'regenerating not duplicating' implies idempotency but doesn't provide context for choice.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

11 tool updatesv1.0.0Jul 28, 2026
- First observedats_report
- First observedbatch_plan
- First observedbatch_render
- First observedget_master_cv
- First observedlist_applications
- First observedoverleaf_commit_push
- First observedoverleaf_sync
- First observedprepare_tailoring
- First observedrender_and_compile
- First observedrender_cover_letter
- First observedupdate_tracker

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation4/5

Most tools have distinct purposes, but the presence of both `render_and_compile` (which can produce a cover letter) and a separate `render_cover_letter` creates some ambiguity. Agents may be uncertain which to use for cover letter generation. Otherwise, tools like `batch_plan` and `batch_render` are clearly paired, and the rest are well-separated.

Naming Consistency3/5

The majority of tools follow a verb_noun pattern (e.g., `list_applications`, `render_and_compile`), but there are inconsistencies: `overleaf_sync` reverses the order (noun_verb), and `overleaf_commit_push` uses two verbs. The naming is still readable, but the mixed conventions detract from predictability.

Tool Count5/5

With 11 tools, the server covers the full workflow from CV retrieval to compilation, batch processing, ATS analysis, and application tracking. Each tool earns its place, and the count is well within the ideal 3-15 range for a focused domain.

Completeness4/5

The toolset covers the essential lifecycle: fetching master CV, tailoring, rendering, batch handling, ATS scoring, and tracking applications. Minor gaps exist, such as no tool for directly editing the master CV or deleting tracker entries, but these are peripheral to the core functionality.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Smart MatchOAuth
io.github.pkhaninejad
Analyze job listings against your resume, track applications, and generate cover letters.
RAG Systems Search AI & Machine Learning
2
Laddro Career AOAuth
com.laddro
Tailor resumes, generate cover letters, render CVs as PDF, and browse 22+ templates.
Workplace & Productivity Search
2
Suited
com.suitedforit
Tailored, graded job applications: a CV, cover letter and form answers built per vacancy.
Workplace & Productivity Content Management Systems
2
keywordise A
com.keywordise
Auto-apply to jobs: matches your CV, tailors a fresh CV per posting, and applies for you.
App Automation Autonomous Agents
491

Related MCP Servers

CV Resume Builder MCP
Developer Tools App Automation Workplace & Productivity
eyaab
A
license
B
quality
D
maintenance
Automatically generates and updates CVs/resumes by aggregating data from git commits, Jira tickets, Credly certifications, and existing PDF resumes, with LaTeX formatting support.
Updated 9 months ago (2025-12-10 13:53 UTC)
14
13
MIT
Resume Generator MCP Server
Workplace & Productivity Developer Tools
AndreaCadonna
A
license
A
quality
C
maintenance
Generates professional PDF resumes using LaTeX templates through natural language descriptions. Supports 9 professional templates, AI-powered resume tailoring, and organized folder management for job applications.
Updated a month ago (2026-08-01 21:22 UTC)
4
23
MIT
Application Tracker MCP
Search Project Management Workplace & Productivity
jrootn
A
license
A
quality
C
maintenance
A privacy-first MCP server for locally managing job, fellowship, and graduate-school applications. It offers tools for tracking application status, analyzing role fit, generating LaTeX CV/cover letters, interview prep, and discovering public jobs from ATS APIs.
Updated a month ago (2026-08-05 23:32 UTC)
8
1
MIT
cv-tailor-mcp
Workplace & Productivity Command Line
AaronUgalde
A
license
Not graded
quality
C
maintenance
Enables users to tailor a one-page LaTeX CV to a job posting by fetching relevant facts from a YAML file, rendering a LaTeX document from id-based selections, and compiling it to PDF, without wasting tokens on repetitive CV reads or compiler logs.
Updated a month ago (2026-08-11 03:30 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/abhi-ramtel/mcp-overleaf-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server