This server connects AI assistants to an AI Applyd account to handle the entire job-search workflow—scoring, tailoring, translating, building, and even auto-submitting applications on real employer ATS platforms.
Score a resume against a specific job description or for general ATS readiness, returning overall/section scores, matched/missing keywords, and rewrite suggestions.
Analyze a job description to extract exact ATS keywords, must-have vs. nice-to-have requirements, seniority signals, and red flags.
Optimize a resume with AI, tailoring it to a posting or for general ATS optimization, with a projected score and itemized change summary.
Generate interview questions for a specific role and company, including company insights, likely questions with guidance, STAR scenarios, talking points, questions to ask, and salary negotiation prep.
Translate a resume saved on the account into another language without modifying the original.
Search jobs by title, location, and remote-only preference, returning match scores, company, location, salary, skills, and application URLs.
Update job preferences to set which roles and locations AI Applyd hunts for (replaces the saved list).
Generate a cover letter from the saved resume for a specific job, in the user's voice and free of clichés.
Apply to one specific job end-to-end by URL, rewriting the resume and cover letter and submitting the application on the employer's own hiring system across major ATS platforms (Workday, Greenhouse, Lever, Ashby, etc.).
Build a resume from raw text into a formatted, ATS-clean, editable PDF via the AI Applyd resume builder, with optional template selection and optional sharing of a public link (only when explicitly requested).
Enables automated job applications to Greenhouse, including resume optimization and direct submission to job postings.
Enables automated job applications to Personio, including resume optimization and direct submission to job postings.
Stop applying. Start interviewing.
Score your resume the way the screening software scores it, rewrite it for the exact role, write the cover letter, prepare for the interview, and send the application in on the employer's own hiring system. All from inside the assistant you already work in.
Listing page · Website · Privacy · Terms
Most applicants are screened out by software before a person reads a word. This server puts the other side of that process in your hands.
Every application goes in on the company's real careers page, under your name, with your own materials. It lands on all twelve major ATS platforms: Workday, Greenhouse, Lever, Ashby, Workable, iCIMS, Personio, Recruitee, Teamtailor, Rippling, Breezy and SmartRecruiters.
Nothing to install. Connect once and run it from Claude, ChatGPT, Cursor or any MCP client.
AI Applyd is a hosted remote MCP server. Point your client at one URL:
https://mcp.aiapplyd.com/mcpThe first tool call opens an OAuth sign-in. Sign in with Google, and you are connected. A free account needs no card and arrives with a one-time 10,000-token starter grant.
Settings → Connectors → Add custom connector
Field | Value |
Name |
|
Remote MCP server URL |
|
In Claude Code, one line does it:
claude mcp add --transport http aiapplyd https://mcp.aiapplyd.com/mcp~/.cursor/mcp.json:
{
"mcpServers": {
"aiapplyd": {
"url": "https://mcp.aiapplyd.com/mcp"
}
}
}Settings → Connectors → Create and paste https://mcp.aiapplyd.com/mcp. ChatGPT speaks MCP
natively, so there is no Action schema to import and nothing to host.
code --add-mcp '{"name":"aiapplyd","type":"http","url":"https://mcp.aiapplyd.com/mcp"}'This repository ships a thin bridge. It relays the protocol to the hosted server and adds nothing of its own.
npx -y github:aiapplyd/aiapplyd-mcpOr with Docker:
docker build -t aiapplyd-mcp .
docker run --rm -i aiapplyd-mcp{
"mcpServers": {
"aiapplyd": {
"command": "docker",
"args": ["run", "--rm", "-i", "aiapplyd-mcp"]
}
}
}Environment variable | Default | Meaning |
|
| Endpoint to relay to. Point it at |
| unset | Optional bearer token. Without it the server still answers introspection; tool calls return 401 until an account is connected. |
Related MCP server: Resume Assistant MCP
Environment | Streamable HTTP (modern) | SSE (legacy bridges) |
Production |
|
|
Preview |
|
|
Use /mcp. /sse remains only for clients that cannot speak Streamable HTTP.
Ten tools. Every one runs on the caller's own AI Applyd account and spends that account's own credits. The server holds no allowance of its own and there is no anonymous tool.
Tool | Read-only | What you get |
| yes | An overall ATS score plus section scores, the keywords you match, the ones you are missing, and what to change |
| yes | What the posting screens on, in its own language |
| yes | The questions this role is asked, with answer guidance and negotiation prep |
| yes | The roles worth pursuing, scored against your profile |
| no | A resume that passes ATS screening and still reaches a human reader |
| no | A send-ready resume in another language, formatted for that market |
| no | A cover letter in your own voice, from the resume already on your account |
| no | A finished, ATS-clean resume, editable in the builder and ready to download |
| destructive | Direct the search at the roles and locations you are targeting. A supplied list replaces the stored one. |
| destructive | One specific job, applied for end to end on the employer's own system |
Every tool declares readOnlyHint and destructiveHint, so a client can tell at a glance
which calls change something in the world.
aiapplyd_search_jobs never writes. It reads your saved matches. To change what
AI Applyd hunts for, call aiapplyd_update_job_preferences.
aiapplyd_auto_apply submits a real application to a real employer. It follows the
review setting already on your account: auto-approve submits on its own, co-pilot routes it
to your review queue. It never changes that setting, and it never applies to anything but
the one job URL you hand it.
Prompt | What it does |
| Scores a resume against a posting and returns the three changes that move it past the filter |
| Prepares the questions this company asks, with structured answers ready |
| The strongest matches for a target role, ranked by fit |
Resource | Contents |
| Canonical ATS rules, keyword strategy, and formatting pitfalls |
| STAR, CARL, SOAR and PAR answer frameworks for behavioural interviews |
| Optimal resume section order by career stage |
OAuth 2.1, and it is the full specification rather than a subset:
PKCE with S256, mandatory
Dynamic Client Registration (RFC 7591), so a client registers itself with no manual key exchange
Authorization Server Metadata (RFC 8414) and Protected Resource Metadata (RFC 9728) discovery
Token revocation (RFC 7009)
Short-lived access tokens with rotating refresh tokens and reuse detection
An unauthenticated tools/call returns HTTP 401 with a WWW-Authenticate header pointing at
the metadata document. Introspection (initialize, tools/list, prompts/list,
resources/list) is open, so any directory or client can read the tool surface before a user
signs in.
SID=$(curl -s -D- -o /dev/null -X POST https://mcp.aiapplyd.com/mcp \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"probe","version":"1"}}}' \
| grep -i '^mcp-session-id' | tr -d '\r' | awk '{print $2}')
curl -s -X POST https://mcp.aiapplyd.com/mcp \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-H "Mcp-Session-Id: $SID" \
-d '{"jsonrpc":"2.0","id":2,"method":"tools/list"}'Your resume and profile stay on your AI Applyd account. Tools read and write that account and nothing else. The privacy policy and terms are the binding statement.
Email: admin@aiapplyd.com
The hosted server runs on Cloudflare Workers and its source is not public. This repository is
the public home of the MCP server: the server.json manifest, the connection documentation,
and the small stdio bridge above. The bridge is MIT licensed and forwards messages verbatim,
so you can read every line of what runs on your machine.
Extract what a job posting actually screens on: the exact ATS keywords, must-have versus nice-to-have requirements, seniority signals, and red flags. Call this before tailoring a resume so the resume mirrors the posting's own language. Requires a connected AI Applyd account and uses the user's AI credits.
| Name | Required | Description | Default |
|---|---|---|---|
| job_description | Yes | Full text of the job description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive. The description adds meaningful behavioral context by noting that it requires a connected AI Applyd account and consumes the user's AI credits, and it summarizes what analysis outputs to expect. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler: the first states the core value, the second gives the call timing, and the third states the prerequisites. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with full schema coverage and safety annotations, the description covers purpose, expected output categories, usage timing, and prerequisites. The absence of an output schema is mitigated by explicitly naming what the extraction returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the sole parameter, job_description, already has a clear description in the schema: 'Full text of the job description.' The tool description reinforces the general use case but adds no new parameter-level detail beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'extract,' and defines the resource as a job posting, then lists concrete output categories: ATS keywords, must-have versus nice-to-have requirements, seniority signals, and red flags. This clearly distinguishes it from sibling tools like aiapplyd_score_resume or aiapplyd_generate_cover_letter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to call this before tailoring a resume, which gives a clear actionable trigger. It does not explicitly mention when not to use it or name alternative tools, but the stated context is sufficient for correct use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply to ONE specific job posting end to end: the resume and cover letter are rewritten for that role, then the form is completed and submitted on the employer's own hiring system, not a job board. All fifteen major ATS platforms land: Workday, Greenhouse, Lever, Ashby, Workable, iCIMS, Personio, Recruitee, Teamtailor, Rippling, Breezy, SmartRecruiters, BambooHR, JazzHR, softgarden. Follows the account's review setting: submits directly, or routes to the review queue. Requires a paid plan (Hired in 30+).
| Name | Required | Description | Default |
|---|---|---|---|
| job_url | Yes | URL of the job posting to apply to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, the description adds crucial behavioral context: it may submit directly or route to a review queue depending on account settings, it rewrites the resume and cover letter, it works across 15 named ATS platforms, and it requires a paid plan. This gives the agent a clear picture of side effects and constraints beyond the destructiveHint annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and then adds relevant scope, platform coverage, review behavior, and prerequisites. The ATS platform list is long but informative; every major claim earns its place. Slightly dense, but not redundant or padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter and no output schema, the description covers what the tool does, the exact prerequisite (paid plan), the behavioral outcome (submission vs review queue), and the supported environments (15 ATS platforms). An agent has enough information to decide whether to invoke it and what to expect, even without a return-value specification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single job_url parameter is already fully documented. The description adds context about applying to 'ONE specific job posting' but does not add parameter-level syntax or format details beyond what the schema already provides, which matches the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Apply to ONE specific job posting end to end.' It clearly describes the full workflow (rewrite resume/cover letter, complete and submit the form) and distinguishes itself from related sub-step tools like generate_cover_letter or optimize_resume by noting it submits on the employer's own hiring system, not a job board.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: whenever a user provides a single job URL and wants an actual application submitted, rather than just a resume score, optimization, or cover letter. It also sets a prerequisite ('Requires a paid plan') and scope ('ONE specific job posting'), though it does not explicitly name sibling alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a formatted, ATS-clean resume from raw text in the user's AI Applyd resume builder, where it stays editable and downloads as a PDF. Templates: modern, classic, or minimal. Private to the account by default; set make_public to true only if the user explicitly asks for a shareable public link. Requires a paid plan (Hired in 30+).
| Name | Required | Description | Default |
|---|---|---|---|
| template | No | Resume template style (default: classic) | |
| make_public | No | Publish a public share link. Anyone with the link sees the resume INCLUDING its contact details. Defaults to false (private). Only set true when the user explicitly asks to share it. | |
| resume_text | Yes | Full text of the resume |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide only a basic safety profile, so the description adds useful behavior: the resume stays editable, downloads as a PDF, defaults to private, and make_public exposes contact details to anyone with the link. The paid-plan prerequisite is also disclosed. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences carry the core action, output, template choices, privacy default, share-link caveat, and plan requirement with no wasted words. The most important function is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 deliverable (PDF download), the editable state, and the key constraints (paid plan, privacy, explicit opt-in for public sharing). Combined with the fully documented input schema, an agent has everything needed to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has a detailed description, so the baseline is 3. The tool description mostly restates the template enum and public-link behavior already present in the schema, adding only minor framing like 'raw text' for resume_text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action ('Build a formatted, ATS-clean resume') and identifies the resource (raw text in the AI Applyd resume builder), the editable state, and the PDF output. It clearly distinguishes this from siblings like aiapplyd_optimize_resume or aiapplyd_score_resume, which concern content improvement or scoring rather than PDF generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear invocation context: use raw resume text, choose a template, default to private, and honor the paid-plan requirement. It also provides a strong conditional rule: only set make_public to true if the user explicitly asks for a shareable public link. It does not explicitly name when-not-to-use or alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write a cover letter for a specific job from the resume already saved on the user's AI Applyd account, in their own voice and free of recruiter cliches. Returns the finished letter and saves it to the account. Requires a paid plan (Hired in 30+).
| Name | Required | Description | Default |
|---|---|---|---|
| company_name | Yes | Name of the company you are applying to | |
| job_description | Yes | Full text of the target job description |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint false, destructiveHint false), the description discloses that the tool reads the saved resume, generates a letter, returns it, and saves it to the account. It also mentions the paid-plan prerequisite. This goes beyond the annotations by explicitly stating the write side-effect (saving) and the dependency on an existing resume, providing meaningful transparency 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It leads with the primary action and context, then covers quality attributes, the return value, the save behavior, and the prerequisite—all in three sentences with no redundancy or unnecessary detail. The information is efficiently packed and front-loaded, making it easy for an agent to parse the core purpose quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential aspects: purpose, input (resume from account), output (returned letter), side effect (saving), and a key constraint (paid plan). It does not mention output format, error handling, or specific edge cases, but for a straightforward cover-letter generator, the provided context is sufficient for an agent to understand when and how to use it. The inclusion of the saved-resume dependency and the paid-plan requirement adds practical completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full descriptions for both parameters (company_name and job_description), achieving 100% coverage. The tool description does not add any additional semantic detail beyond what the schema specifies—it references 'a specific job' but does not elaborate on parameter meanings, constraints, or interdependencies. Since schema coverage is high, the baseline of 3 applies, and the description adds no incremental value for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's primary action—writing a cover letter for a specific job—and specifies the source (resume on the user's account), the style (own voice, no clichés), and the output (returns the letter). It also notes the side effect of saving, making the purpose unmistakable and distinct from sibling tools like resume optimization or interview question generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when a cover letter for a job is needed) but does not explicitly contrast it with alternatives or provide conditional guidance. Sibling tools such as optimize_resume or generate_interview_questions are not referenced, so users must infer the appropriate choice from the stated purpose. The paid-plan requirement is mentioned, which is useful context, but it does not constitute usage guidance relative to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Produce interview preparation for a specific role and company: company insights, the questions this role is asked with approach guidance, STAR scenarios drawn from the posting, talking points, questions to ask the interviewer, and salary negotiation prep. Requires a connected AI Applyd account.
| Name | Required | Description | Default |
|---|---|---|---|
| job_title | Yes | Title of the position (e.g. "Senior Software Engineer") | |
| company_name | Yes | Name of the company | |
| job_description | No | Full text of the job description (optional but recommended for better results) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint and destructiveHint annotations already indicate no side effects, and the description adds the important authentication requirement of a connected AI Applyd account. It does not contradict the annotations and provides additional behavioral context beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that lists the key outputs efficiently. It includes the necessary authentication caveat without unnecessary verbosity, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides a thorough list of what the tool will generate, covering all major aspects of interview prep. It also notes the account requirement and the optional job description, making it complete for an agent to decide to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all three parameters with clear descriptions. The description adds semantic value by linking job_description to 'STAR scenarios drawn from the posting', clarifying how that optional parameter influences the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as producing interview preparation for a specific role and company. It lists the specific outputs (company insights, questions, STAR scenarios, talking points, etc.), making it distinct from sibling tools like cover letter generation or resume scoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when interview preparation is needed for a role and company) and states the prerequisite of a connected AI Applyd account. However, it does not explicitly contrast with alternative tools or state when not to use it, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rewrite a resume so it passes ATS screening. Returns the rewritten resume, a projected ATS score, and an itemised summary of every change made. Pass job_description to tailor the rewrite to one specific posting, or omit it for general ATS optimization. Requires a connected AI Applyd account.
| Name | Required | Description | Default |
|---|---|---|---|
| resume_text | Yes | Full text of the resume to optimize | |
| job_description | No | Full text of the target job description (optional, omit for general ATS optimization) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a behavioral prerequisite ('Requires a connected AI Applyd account') and outlines the output (rewritten resume, score, summary) beyond the annotations. However, it does not disclose any side effects (e.g., whether it modifies stored data), relying on annotations for readOnly and destructive hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using three sentences to cover purpose, output, parameter usage, and account requirement. There is no redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers what the tool does, its parameters, and its output. It even mentions the account requirement. Given the simplicity of the tool and no output schema, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, but the description adds extra context for 'job_description' by explaining the tailoring vs. general use case, which goes beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (rewrite), the resource (resume), and the goal (pass ATS screening). It also distinguishes itself from siblings by mentioning it returns a rewritten resume, score, and summary, and how it can be tailored with a job description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to include the optional 'job_description' parameter (to tailor) versus omit it (for general optimization). It does not explicitly name alternatives like 'aiapplyd_score_resume', but the parameter usage guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score a resume for ATS compatibility. Returns an overall score, section scores, the keywords the resume matches and the ones it is missing, and specific rewrite suggestions. Pass job_description to score against a posting, or omit it for a general ATS readiness score. Requires a connected AI Applyd account and uses the user's credits.
| Name | Required | Description | Default |
|---|---|---|---|
| resume_text | Yes | Full text of the resume | |
| job_description | No | Full text of the job description (optional, omit for a general ATS readiness score) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite the readOnlyHint annotation, the description transparently discloses a key behavioral side effect: it uses the user's credits. It also mentions the need for a connected account, which is an authorization requirement. This adds valuable context beyond the annotations and makes side effects clear to the user.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: the first sentence states the core purpose, the second summarizes outputs, and the third handles the optional parameter usage. It is front-loaded and free of redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, no output schema), the description is contextually complete. It covers what the tool does, what it returns, when to use the optional parameter, and prerequisites. No critical information is missing for a basic understanding of how to invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (resume_text and job_description) are fully described in the schema with clear explanations of their content and optionality. The tool description reinforces the role of job_description, providing complete semantic coverage for the parameter set.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's primary function: scoring a resume for ATS compatibility. It details the specific outputs (overall score, section scores, keyword matches/misses, rewrite suggestions), which effectively distinguishes it from sibling tools like optimize_resume or analyze_job_description. The mention of optional job_description further clarifies two distinct usage modes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage guidance by explaining when to include job_description (to score against a posting) and when to omit it (for a general readiness score). It also notes the prerequisite of a connected account. However, it does not explicitly compare this tool to alternatives like optimize_resume, leaving some ambiguity about when to choose scoring over optimization or analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the user's AI-curated job matches, filtered by title, location, and remote preference. Each match carries a match score, company, location, salary, extracted skills, and the application URL. Read-only: it never changes which roles AI Applyd hunts for (use aiapplyd_update_job_preferences for that). Requires a connected AI Applyd account.
| Name | Required | Description | Default |
|---|---|---|---|
| location | No | Preferred location (e.g. "San Francisco, CA", "New York", "Remote") | |
| job_title | Yes | Job title to search for (e.g. "Software Engineer", "Product Manager") | |
| remote_only | No | If true, only show remote-friendly positions |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds concrete context: it never changes which roles AI Applyd hunts for, requires a connected account, and spells out the match fields returned. This goes beyond the structured hints without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no filler: purpose and filters first, then return contents, then safety/alternative/requirement. Every sentence carries useful signal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is no output schema, the description lists the match fields (score, company, location, salary, skills, application URL), covers the prerequisite, and clarifies the read-only boundary. Nothing an agent needs to invoke or interpret the result is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter already has a clear description. The tool description only echoes the filter dimensions (title, location, remote preference), so it adds no significant semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific action ('Return'), the resource ('user's AI-curated job matches'), and the filtering dimensions (title, location, remote preference). It also distinguishes itself from aiapplyd_update_job_preferences, so an agent can tell it apart from its sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the read-only scope, explicitly routes preference changes to aiapplyd_update_job_preferences, and notes the connected-account prerequisite. It doesn't enumerate all when-not-to-use cases versus the broader sibling list, but for a search tool the key alternative is addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Translate the resume saved on the user's AI Applyd account into another language, ready to send to employers in that market. Saves the translation as a new resume and leaves the original unchanged. Requires a connected AI Applyd account.
| Name | Required | Description | Default |
|---|---|---|---|
| target_language | Yes | Target language (e.g. "Spanish", "French", "German", "Japanese") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by explicitly explaining that the tool creates a new resume, leaves the original unchanged, and requires a connected AI Applyd account. It does not cover every failure mode or output detail, but it transparently describes the main side effects and prerequisite.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with the action and outcome up front. It includes necessary side-effect and prerequisite information without any filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description covers the prerequisite, the side effect, and the intended use context. It leaves only minor ambiguity about which resume is used if the user has multiple resumes on their account, but it is otherwise complete enough for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, target_language, is fully covered by the schema with an example and length constraints. The description does not add any additional parameter-specific constraints or clarification beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (translate), the resource (the resume saved on the user's AI Applyd account), and the outcome (saves a translation as a new resume while leaving the original unchanged). This clearly differentiates it from sibling tools like score, optimize, cover letter generation, and auto apply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description communicates when the tool is useful by mentioning it is for sending resumes to employers in another language, but it does not explicitly name alternative tools or state when not to use this tool. The usage is strongly implied by the translation focus, but not explicitly contrasted with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the roles and locations AI Applyd hunts for on the user's behalf, and re-run discovery immediately. This REPLACES the target roles / locations currently saved on the account, so pass the complete list you want, not just an addition. Only call this when the user explicitly asks to change what they are looking for. Requires a connected AI Applyd account.
| Name | Required | Description | Default |
|---|---|---|---|
| locations | No | Full list of preferred locations. REPLACES the saved list. | |
| remote_only | No | Whether to include remote-friendly positions | |
| target_roles | No | Full list of job titles to hunt for. REPLACES the saved list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral detail beyond the annotations: the operation REPLACES saved lists, re-runs discovery immediately, and requires a connected account. These details align with destructiveHint=true and idempotentHint=true and help the agent anticipate side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary action, followed by the critical replacement warning, the invocation condition, and the prerequisite. Every sentence carries useful information and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema, the description covers what the tool does, its side effects, when to call it, and what is required before calling it. This is sufficient for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The prose description repeats the 'pass the complete list, not just an addition' warning, which reinforces the schema, but it does not add meaning beyond what the parameter descriptions already state.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Set the roles and locations'), names the resource (job preferences), and distinguishes this tool from siblings like search_jobs or auto_apply by emphasizing it changes saved preferences and re-runs discovery. The 'REPLACES' warning makes the scope unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit invocation condition: 'Only call this when the user explicitly asks to change what they are looking for.' This also implies when not to call it, which is strong guidance. There are no direct sibling alternatives for updating preferences, so not naming an alternative is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.3.0aiapplyd_analyze_job_descriptionaiapplyd_auto_applyaiapplyd_build_pdfaiapplyd_generate_cover_letteraiapplyd_generate_interview_questionsaiapplyd_optimize_resumeaiapplyd_score_resumeaiapplyd_search_jobsaiapplyd_translate_resumeaiapplyd_update_job_preferencesScored across 10 tools
Each tool has a distinct, well-scoped purpose—scoring, analyzing, optimizing, generating, translating, searching, updating preferences, and building PDFs. No two tools overlap ambiguously; descriptions clearly differentiate read-only vs. mutating operations.
All tool names follow the exact same pattern: aiapplyd_verb_noun (e.g., score_resume, analyze_job_description, update_job_preferences). This is highly predictable and makes the toolset easy to navigate.
Ten tools is well within the ideal range for a job-application assistant. Each tool maps to a meaningful step in the workflow, and none feel redundant or unnecessary.
The toolset covers the full job-application lifecycle: resume analysis and optimization, cover letters, interview prep, job search, preference management, translation, and auto-application. No obvious critical gap exists for the stated domain.
Honest resume/cover tailor for agents. Free generate; Stripe unlock for downloads. Streamable HTTP.
Auto-apply to jobs: matches your CV, tailors a fresh CV per posting, and applies for you.
Tailored, graded job applications: a CV, cover letter and form answers built per vacancy.
Analyze job listings against your resume, track applications, and generate cover letters.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/aiapplyd/aiapplyd-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
