Resume-Tailor MCP Server

by NmaaAlhawary

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a distinct, non-overlapping purpose: fetching job posts, extracting keywords, analyzing gaps, managing the master resume, and exporting. An agent can clearly distinguish them.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., fetch_job_posting, extract_keywords), making them predictable and easy to understand.
Tool Count5/5
With 6 tools, the scope is well-balanced: each tool serves a necessary step in the resume tailoring workflow without redundancy or excessive complexity.
Completeness4/5
The set covers the core pipeline from job posting to export, but lacks a dedicated tool to save tailored resume versions separately from the master. This minor gap is manageable for agents.
Average 4.4/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 28 commits in the last 12 weeks
- Last stable release on July 16, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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 persistence and returns a confirmation path, but lacks details on update behavior, validation, error handling, or constraints (e.g., size limits). The phrase 'Store or update' implies idempotence but is not explicit.
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 well-structured: a clear first sentence, a helpful block of recommended keys, and a concluding sentence about the flow and return value. Slightly verbose due to the key list, but it's practical and front-loaded.
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?
Given the tool has one nested parameter and an output schema (not detailed in input), the description covers the input structure well but only briefly mentions the return value ('confirmation with the stored path'). Missing details on output format, behavior on overwrite, or error cases. Adequate but not fully 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?
The schema defines a single object parameter 'resume' with additionalProperties: true, providing no structure. The description adds significant value by listing recommended keys and their structure (contact, summary, experience, projects, skills, education), though it notes these are recommended, not required.
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: 'Store or update the user's base CV so it persists between sessions.' It distinguishes from siblings by calling this 'step 1 of the flow' and contrasting with load_master_resume and export_resume.
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 clear context: 'This is step 1 of the flow: set it up once, reuse it for every job.' It implies when to use but does not explicitly state when not to use or provide alternative tool names (though sibling context exists).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of disclosure. It describes the return format (match_score, matched, missing, total_keywords) and states it 'tells the user *concretely* what to add.' However, it does not mention idempotency, permissions, side effects, or rate limits. For a read-like operation, this is adequate but not thorough.
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 paragraphs plus a line showing the return format. The first sentence is front-loaded with the core purpose. The second paragraph adds context but could be slightly more concise without losing clarity. Overall, it efficiently communicates necessary information.
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 simplicity (2 parameters, output schema exists) and the presence of sibling tools, the description provides sufficient context: it explains inputs, outputs, and usage with extract_keywords. The return format is described in text despite an output schema. It covers the essential information for an agent to invoke 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?
The input schema has 0% description coverage, but the description adds valuable semantics: it clarifies that resume_text should be 'plain text' and that keywords should be 'the ranked keyword list from extract_keywords.' This goes beyond the schema to guide correct parameter 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 explicitly states the tool's function: 'Compare a CV against job keywords → match score (%) + missing terms.' It clearly identifies the resources (CV/resume and keywords) and the outcome (match score and missing terms). It also distinguishes itself from sibling tools like extract_keywords by describing its unique value as a 'killer feature' that tells the user exactly what to add.
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 clear guidance on when to use: 'Pass the resume as plain text and the ranked keyword list from extract_keywords.' It implies the tool should be used after extract_keywords and before rewriting. While it doesn't explicitly state when not to use or list alternatives, the context is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the tool's behavior: deterministic, tokenizes, filters filler words, recognizes skills and phrases, ranks by frequency with boosting. It also states the return format, leaving no ambiguity about what the tool does.
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 and well-structured: a lead sentence explaining the purpose, a sentence on the algorithm, a sentence on the output format, and a final usage recommendation. Every sentence adds value with no redundancy.
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 has two parameters and no annotations, the description covers purpose, algorithm, output, and usage. It lacks details on error handling or input constraints (e.g., what happens with empty text or extreme top_n values), but for a straightforward extraction tool, it is largely complete.
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 schema has 0% parameter description coverage, so the description must compensate. It only implicitly covers job_text (the text to tokenize) but does not mention top_n at all, leaving a parameter undocumented. Although the output format is described, the optional parameter's effect on ranking is omitted.
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 that the tool extracts skills/tools/keywords from job postings using a deterministic method. It specifies the exact verb 'pull' and resource 'job posting', and distinguishes itself from siblings by focusing on keyword extraction for ATS scanning.
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 recommends using the output as input to a sibling tool (ats_gap_check), providing clear usage context. However, it does not specify when not to use this tool or mention any prerequisites like using fetch_job_posting first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses output format traits: ATS-safe, single-column, real text. It also describes the return object shape. It does not mention file overwrite behavior or error conditions, but covers key behavioral attributes.
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?
Four sentences with no wasted words. Purpose, content guidelines, format and layout, and return type are each clearly stated in a logical order.
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?
The description covers input formats, output format, layout properties, and return structure. Missing details on filename behavior or error handling are minor given the output schema exists. Complete for standard use cases.
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?
Despite 0% schema description coverage, the description explains the content parameter (markdown vs structured JSON with syntax hints) and format parameter (pdf/docx). The filename parameter is not described, but overall adds significant value beyond 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 it renders CV content to PDF/DOCX, specifying both input formats and output options. It differentiates from sibling tools like load_master_resume and save_master_resume by focusing on final export.
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 usage after resume completion ('Render finished CV content') and gives detailed formatting instructions. However, it does not explicitly contrast with siblings or specify 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.
Behavior5/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 transparently discloses that URL fetching is 'best-effort,' that it 'never fails silently,' and returns a clear message on failure. It also explicitly lists the return fields {source, text, char_count}, leaving no ambiguity about the tool's behavior.
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 remarkably concise: four sentences covering purpose, parameters, behavior, and return format. Every sentence adds essential information with no redundancy. It is well-structured with the first sentence as an effective summary.
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 simplicity, the description covers all relevant aspects: input modes, failure behavior (blocked/login-walled), and output structure ({source, text, char_count}). It is complete enough for an agent to understand when and how to invoke the tool without external documentation.
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 0% schema description coverage, the description must compensate, and it does by explaining the roles of 'url' (to fetch and strip a posting) and 'pasted_text' (for direct input). This adds semantic meaning beyond the schema's type/default. However, it could include more detail like URL format expectations or text length limits.
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 'Get a job posting as clean readable text.' It specifies two distinct modes (URL or pasted_text), making the tool's purpose unambiguous. While it doesn't explicitly contrast with siblings, the verb 'fetch' and resource 'job posting' are specific enough to differentiate from tools like ats_gap_check or export_resume.
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 strong usage guidance by explaining when to use URL vs pasted_text, including the fallback behavior: 'if the site is blocked or login-walled, this returns a clear message asking the user to paste the text instead.' It doesn't compare to sibling tools, but within the tool itself, it gives clear context on effective use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses core behavior (returns stored CV) and error handling (raises clear error if none stored), which is comprehensive given no 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?
Two sentences, front-loaded with purpose, zero waste, every sentence adds value.
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?
Complete for a simple read operation with output schema present; description covers purpose, usage context, and error case.
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 (schema coverage 100%), so baseline 4 applies; description adds no param info but 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?
Explicitly states 'Return the stored master CV' with a specific verb and resource, and distinguishes from siblings like save_master_resume by calling it the 'starting point of every tailoring session'.
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?
Clearly states when to use ('starting point of every tailoring session'), provides error context, and though no explicit exclusions, the sibling list implies alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![MCP-Resume-Tailor MCP server](https://glama.ai/mcp/servers/NmaaAlhawary/MCP-Resume-Tailor/badges/card.svg)](https://glama.ai/mcp/servers/NmaaAlhawary/MCP-Resume-Tailor)

Score Badge

Copy to your README.md:

[![MCP-Resume-Tailor MCP server](https://glama.ai/mcp/servers/NmaaAlhawary/MCP-Resume-Tailor/badges/score.svg)](https://glama.ai/mcp/servers/NmaaAlhawary/MCP-Resume-Tailor)

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/NmaaAlhawary/MCP-Resume-Tailor'

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