The serious candidate's edge: ATS scoring, per-role resumes, interview prep, applications sent.
Scored across 10 tools
Each tool has a distinct purpose: job description analysis, resume optimization/scoring/translation, cover letter generation, job search/preference updates, auto-apply, PDF builder, and interview prep. No two tools overlap in functionality; the clear separation between optimize and score, and between search and update preferences, avoids ambiguity.
All tools share the same 'aiapplyd_' prefix and follow a consistent verb_noun pattern (e.g., analyze_job_description, generate_cover_letter, update_job_preferences). Minor deviation: 'build_pdf' and 'auto_apply' are slightly less descriptive but still fit the pattern.
Ten tools is well-scoped for a job application automation server. Each tool covers a distinct step in the workflow from job discovery to application submission, with no redundancy and a reasonable total count that is neither excessive nor too thin.
The tool set covers the entire job application lifecycle: discovery (search, preferences), targeting (analyze job description), resume actions (optimize, score, translate, build), cover letter generation, application submission (auto-apply), and post-application (interview prep). No essential operation appears missing for a comprehensive service.
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.
aiapplyd_analyze_job_description1 field changedInput schema / properties / localeRemoved value: -{
- "description": "Language for the human-readable parts of the answer: en, es, de, fr or pt-BR. Defaults to the language this connection was opened in. Machine fields (ids, URLs, scores) never change.",
- "enum": [
- "en",
- "es",
- "de",
- "fr",
- "pt-BR"
- ],
- "type": "string"
-}aiapplyd_auto_apply1 field changedInput schema / properties / localeRemoved value: -{
- "description": "Language for the human-readable parts of the answer: en, es, de, fr or pt-BR. Defaults to the language this connection was opened in. Machine fields (ids, URLs, scores) never change.",
- "enum": [
- "en",
- "es",
- "de",
- "fr",
- "pt-BR"
- ],
- "type": "string"
-}aiapplyd_build_pdf1 field changedInput schema / properties / localeRemoved value: -{
- "description": "Language for the human-readable parts of the answer: en, es, de, fr or pt-BR. Defaults to the language this connection was opened in. Machine fields (ids, URLs, scores) never change.",
- "enum": [
- "en",
- "es",
- "de",
- "fr",
- "pt-BR"
- ],
- "type": "string"
-}aiapplyd_generate_cover_letter1 field changedInput schema / properties / localeRemoved value: -{
- "description": "Language for the human-readable parts of the answer: en, es, de, fr or pt-BR. Defaults to the language this connection was opened in. Machine fields (ids, URLs, scores) never change.",
- "enum": [
- "en",
- "es",
- "de",
- "fr",
- "pt-BR"
- ],
- "type": "string"
-}aiapplyd_generate_interview_questions1 field changedInput schema / properties / localeRemoved value: -{
- "description": "Language for the human-readable parts of the answer: en, es, de, fr or pt-BR. Defaults to the language this connection was opened in. Machine fields (ids, URLs, scores) never change.",
- "enum": [
- "en",
- "es",
- "de",
- "fr",
- "pt-BR"
- ],
- "type": "string"
-}aiapplyd_optimize_resume1 field changedInput schema / properties / localeRemoved value: -{
- "description": "Language for the human-readable parts of the answer: en, es, de, fr or pt-BR. Defaults to the language this connection was opened in. Machine fields (ids, URLs, scores) never change.",
- "enum": [
- "en",
- "es",
- "de",
- "fr",
- "pt-BR"
- ],
- "type": "string"
-}aiapplyd_score_resume1 field changedInput schema / properties / localeRemoved value: -{
- "description": "Language for the human-readable parts of the answer: en, es, de, fr or pt-BR. Defaults to the language this connection was opened in. Machine fields (ids, URLs, scores) never change.",
- "enum": [
- "en",
- "es",
- "de",
- "fr",
- "pt-BR"
- ],
- "type": "string"
-}aiapplyd_search_jobs1 field changedInput schema / properties / localeRemoved value: -{
- "description": "Language for the human-readable parts of the answer: en, es, de, fr or pt-BR. Defaults to the language this connection was opened in. Machine fields (ids, URLs, scores) never change.",
- "enum": [
- "en",
- "es",
- "de",
- "fr",
- "pt-BR"
- ],
- "type": "string"
-}aiapplyd_translate_resume1 field changedInput schema / properties / localeRemoved value: -{
- "description": "Language for the human-readable parts of the answer: en, es, de, fr or pt-BR. Defaults to the language this connection was opened in. Machine fields (ids, URLs, scores) never change.",
- "enum": [
- "en",
- "es",
- "de",
- "fr",
- "pt-BR"
- ],
- "type": "string"
-}aiapplyd_update_job_preferences1 field changedInput schema / properties / localeRemoved value: -{
- "description": "Language for the human-readable parts of the answer: en, es, de, fr or pt-BR. Defaults to the language this connection was opened in. Machine fields (ids, URLs, scores) never change.",
- "enum": [
- "en",
- "es",
- "de",
- "fr",
- "pt-BR"
- ],
- "type": "string"
-}aiapplyd_analyze_job_description1 field changedInput schema / properties / localeAdded value: +{
+ "description": "Language for the human-readable parts of the answer: en, es, de, fr or pt-BR. Defaults to the language this connection was opened in. Machine fields (ids, URLs, scores) never change.",
+ "enum": [
+ "en",
+ "es",
+ "de",
+ "fr",
+ "pt-BR"
+ ],
+ "type": "string"
+}aiapplyd_auto_apply1 field changedInput schema / properties / localeAdded value: +{
+ "description": "Language for the human-readable parts of the answer: en, es, de, fr or pt-BR. Defaults to the language this connection was opened in. Machine fields (ids, URLs, scores) never change.",
+ "enum": [
+ "en",
+ "es",
+ "de",
+ "fr",
+ "pt-BR"
+ ],
+ "type": "string"
+}aiapplyd_build_pdf1 field changedInput schema / properties / localeAdded value: +{
+ "description": "Language for the human-readable parts of the answer: en, es, de, fr or pt-BR. Defaults to the language this connection was opened in. Machine fields (ids, URLs, scores) never change.",
+ "enum": [
+ "en",
+ "es",
+ "de",
+ "fr",
+ "pt-BR"
+ ],
+ "type": "string"
+}aiapplyd_generate_cover_letter1 field changedInput schema / properties / localeAdded value: +{
+ "description": "Language for the human-readable parts of the answer: en, es, de, fr or pt-BR. Defaults to the language this connection was opened in. Machine fields (ids, URLs, scores) never change.",
+ "enum": [
+ "en",
+ "es",
+ "de",
+ "fr",
+ "pt-BR"
+ ],
+ "type": "string"
+}aiapplyd_generate_interview_questions1 field changedInput schema / properties / localeAdded value: +{
+ "description": "Language for the human-readable parts of the answer: en, es, de, fr or pt-BR. Defaults to the language this connection was opened in. Machine fields (ids, URLs, scores) never change.",
+ "enum": [
+ "en",
+ "es",
+ "de",
+ "fr",
+ "pt-BR"
+ ],
+ "type": "string"
+}aiapplyd_optimize_resume2 fields changedInput schema / properties / job_description / descriptionPrevious value: -"Full text of the target job description (optional -- omit for general ATS optimization)"New value: +"Full text of the target job description (optional, omit for general ATS optimization)"Input schema / properties / localeAdded value: +{
+ "description": "Language for the human-readable parts of the answer: en, es, de, fr or pt-BR. Defaults to the language this connection was opened in. Machine fields (ids, URLs, scores) never change.",
+ "enum": [
+ "en",
+ "es",
+ "de",
+ "fr",
+ "pt-BR"
+ ],
+ "type": "string"
+}aiapplyd_score_resume2 fields changedInput schema / properties / job_description / descriptionPrevious value: -"Full text of the job description (optional -- omit for a general ATS readiness score)"New value: +"Full text of the job description (optional, omit for a general ATS readiness score)"Input schema / properties / localeAdded value: +{
+ "description": "Language for the human-readable parts of the answer: en, es, de, fr or pt-BR. Defaults to the language this connection was opened in. Machine fields (ids, URLs, scores) never change.",
+ "enum": [
+ "en",
+ "es",
+ "de",
+ "fr",
+ "pt-BR"
+ ],
+ "type": "string"
+}aiapplyd_search_jobs1 field changedInput schema / properties / localeAdded value: +{
+ "description": "Language for the human-readable parts of the answer: en, es, de, fr or pt-BR. Defaults to the language this connection was opened in. Machine fields (ids, URLs, scores) never change.",
+ "enum": [
+ "en",
+ "es",
+ "de",
+ "fr",
+ "pt-BR"
+ ],
+ "type": "string"
+}aiapplyd_translate_resume1 field changedInput schema / properties / localeAdded value: +{
+ "description": "Language for the human-readable parts of the answer: en, es, de, fr or pt-BR. Defaults to the language this connection was opened in. Machine fields (ids, URLs, scores) never change.",
+ "enum": [
+ "en",
+ "es",
+ "de",
+ "fr",
+ "pt-BR"
+ ],
+ "type": "string"
+}aiapplyd_update_job_preferences1 field changedInput schema / properties / localeAdded value: +{
+ "description": "Language for the human-readable parts of the answer: en, es, de, fr or pt-BR. Defaults to the language this connection was opened in. Machine fields (ids, URLs, scores) never change.",
+ "enum": [
+ "en",
+ "es",
+ "de",
+ "fr",
+ "pt-BR"
+ ],
+ "type": "string"
+}aiapplyd_generate_cover_letter1 field changedInput schema / properties / toneRemoved value: -{
- "description": "Writing tone (default: professional)",
- "enum": [
- "professional",
- "conversational",
- "enthusiastic"
- ],
- "type": "string"
-}aiapplyd_translate_resume2 fields changedInput schema / properties / resume_textRemoved value: -{
- "description": "Full text of the resume to translate",
- "maxLength": 50000,
- "minLength": 50,
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "resume_text",
- "target_language"
-]New value: +[
+ "target_language"
+]aiapplyd_update_job_preferences6 fields changedInput schema / properties / locations / items / maxLengthRemoved value: -200Input schema / properties / locations / items / minLengthRemoved value: -1Input schema / properties / locations / maxItemsRemoved value: -20Input schema / properties / target_roles / items / maxLengthRemoved value: -200Input schema / properties / target_roles / items / minLengthRemoved value: -2Input schema / properties / target_roles / maxItemsRemoved value: -20aiapplyd_analyze_job_descriptionaiapplyd_auto_applyaiapplyd_build_pdfaiapplyd_generate_cover_letteraiapplyd_generate_interview_questionsaiapplyd_optimize_resumeaiapplyd_score_resumeaiapplyd_search_jobsaiapplyd_translate_resumeaiapplyd_update_job_preferencesanalyze_job_descriptionauto_applybuild_pdfgenerate_cover_lettergenerate_interview_questionsoptimize_resumescore_resumesearch_jobstranslate_resumeupdate_job_preferencesauto_apply1 field changedInput schema / properties / resume_textRemoved value: -{
- "description": "Full text of your resume (uses your default resume if not provided)",
- "maxLength": 50000,
- "minLength": 50,
- "type": "string"
-}build_pdf2 fields changedInput schema / properties / make_publicAdded value: +{
+ "description": "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.",
+ "type": "boolean"
+}Input schema / properties / resume_text / descriptionPrevious value: -"Full text of the resume to convert to PDF"New value: +"Full text of the resume"generate_cover_letter2 fields changedInput schema / properties / resume_textRemoved value: -{
- "description": "Full text of your resume",
- "maxLength": 50000,
- "minLength": 50,
- "type": "string"
-}Input schema / requiredPrevious value: -[
- "resume_text",
- "job_description",
- "company_name"
-]New value: +[
+ "job_description",
+ "company_name"
+]score_resume2 fields changedInput schema / properties / job_description / descriptionPrevious value: -"Full text of the job description"New value: +"Full text of the job description (optional -- omit for a general ATS readiness score)"Input schema / requiredPrevious value: -[
- "resume_text",
- "job_description"
-]New value: +[
+ "resume_text"
+]score_resume_aiupdate_job_preferencesanalyze_job_descriptionauto_applybuild_pdfgenerate_cover_lettergenerate_interview_questionsoptimize_resumescore_resumescore_resume_aisearch_jobstranslate_resumeTailored, graded job applications: a CV, cover letter and form answers built per vacancy.
Find jobs, improve resumes, prepare for interviews, and manage your application pipeline.
A job-search companion: tailor your CV to a role, score fit, fix ATS issues. Also via MCP.
Search jobs, tailor your resume, write cover letters, and file applications for you.
Add one secure layer between your agents and this server.
