ATS resume scoring, job analysis, interview prep, and auto-apply that verifies each submission.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.3/5 across 10 of 10 tools scored.
Each tool targets a distinct action or resource: analyzing job descriptions, applying, building PDFs, generating cover letters, generating interview questions, optimizing resumes, scoring resumes, searching jobs, translating resumes, and updating preferences. There is no overlap where two tools appear to do the same thing; even score_resume and optimize_resume are clearly diagnostic versus remedial.
All tools share the consistent 'aiapplyd_' prefix and follow a clear verb_noun pattern (e.g., analyze_job_description, generate_cover_letter, update_job_preferences). The naming is uniform and predictable, with no mixed conventions or vague verbs.
At 10 tools, the server is well-scoped for a job-application assistant, covering the full pipeline from job preferences and search through resume optimization, cover letters, and auto-apply. Each tool earns its place without unnecessary redundancy.
The tool set covers the complete user journey: setting preferences, finding jobs, analyzing postings, scoring/optimizing/translating resumes, building PDFs, generating cover letters and interview prep, and applying. No critical dead ends are apparent for the stated purpose.
aiapplyd_analyze_job_descriptionAnalyze Job DescriptionAExtract 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?
Beyond the readOnlyHint annotation, the description discloses that the tool requires a connected AI Applyd account and consumes the user's AI credits. This is important behavioral context about authentication and side effects (resource consumption) not captured by the annotations. It does not contradict 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 long, front-loaded with the core purpose, and each sentence adds value: what it extracts, when to use it, and prerequisites. There is no redundant or vague wording, making it highly concise and effective.
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 simple one-parameter tool with no output schema, the description covers the core purpose, usage timing, prerequisites, and even enumerates the types of information it extracts (ATS keywords, requirements, seniority signals, red flags). It does not specify the exact return format, but this is a minor gap given the simplicity of the tool.
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 input schema already provides full coverage (100%) with the parameter description 'Full text of the job description'. The tool description reinforces that the input is the job posting text but adds no new constraints, format details, or examples. Baseline 3 is appropriate given the schema covers the parameter well.
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 specifies exactly what the tool does: extracts ATS keywords, must-have vs. nice-to-have requirements, seniority signals, and red flags from a job description. It uses a specific verb ('extract') and resource ('job posting'), and the detail distinguishes it from sibling tools like resume scoring or optimization.
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 states when to use the tool: 'Call this before tailoring a resume so the resume mirrors the posting's own language.' This gives clear contextual guidance. However, it does not explicitly mention alternatives or when not to use it, so it falls 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.
aiapplyd_auto_applyAuto Apply to JobAApply 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 twelve major ATS platforms land: Workday, Greenhouse, Lever, Ashby, Workable, iCIMS, Personio, Recruitee, Teamtailor, Rippling, Breezy, SmartRecruiters. 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?
The description discloses that the tool rewrites the resume and cover letter, completes and submits the form, and follows the account's review setting (direct submit or review queue). This adds behavioral context beyond the annotations' destructiveHint and openWorldHint. It also mentions the paid plan requirement, which is a critical constraint. It does not detail side effects like whether the rewrite overwrites existing documents, but annotations already flag destructiveness.
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 compact and front-loaded, with the first sentence stating the core action. Each subsequent sentence adds value: platform compatibility, review setting, and pricing requirement. There is no filler or redundant repetition.
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 parameter and no output schema, the description covers the main operational aspects: what happens (rewriting, submission), where (employer's system), supported platforms, review behavior, and prerequisites (paid plan). It does not explain return values or error handling, but given the simple input, this is a minor gap. Overall, it is sufficiently 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 fully describes the only parameter (job_url) with 100% coverage, giving a baseline of 3. The description adds some context by emphasizing 'ONE specific job posting' and listing supported ATS platforms, implying the URL must be from one of those. This adds a small amount of meaning beyond the schema but does not elaborate on format or constraints.
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 applies to ONE specific job posting end to end, including rewriting resume/cover letter and submitting on the employer's own hiring system. This distinguishes it from sibling tools like analyze_job_description, optimize_resume, and generate_cover_letter, which handle individual components. The specificity of 'end to end' and 'not a job board' leaves no ambiguity.
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 this is the final step in the job application process, used only when submitting to a specific posting, and requires a paid plan. It lists supported ATS platforms, giving a clear scope of when it will work. However, it does not explicitly name alternatives or state when not to use it, such as for multiple jobs or unsupported platforms.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
aiapplyd_build_pdfBuild ResumeAInspectBuild 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?
The description discloses several behavioral traits beyond the annotations: the resume remains editable, downloads as a PDF, defaults to private with make_public only when explicitly requested, and requires a paid plan. This adds meaningful context about side effects (public link creation) and prerequisites not covered by the annotations. No contradiction with any 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 four sentences, front-loaded with the primary purpose, and each sentence carries meaningful information (output format, templates, privacy, paid plan). No filler or redundant content, though it could be slightly more compact.
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?
No output schema exists, so the description must clarify the return value. It says 'downloads as a PDF,' which implies a PDF output, but it does not specify whether the tool returns a link, binary content, or a confirmation. Overall, it covers the essential context for invocation, including side effects and requirements.
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%, so the baseline is 3. The description repeats the template enum and the make_public privacy behavior, but these are already fully described in the schema. It adds minimal extra meaning beyond what the schema provides, so a 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 states a specific action: 'Build a formatted, ATS-clean resume from raw text' in the user's AI Applyd resume builder, with output as an editable PDF. It clearly distinguishes itself from sibling tools like optimize_resume or score_resume by focusing on the build/format action and 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?
The description provides clear context on when to use the tool—for building a resume from raw text with a choice of templates, and it notes the paid plan requirement and privacy default. It does not explicitly name alternative tools or state 'when not to use,' but the context is unambiguous enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
aiapplyd_generate_cover_letterGenerate Cover LetterAInspectWrite 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?
The description discloses important behavioral traits beyond annotations: it saves the letter (write side-effect) and requires a paid plan. It also mentions the output style (user's voice, no cliches). This adds meaningful context beyond the readOnlyHint=false annotation, with no contradiction.
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 two sentences, front-loaded with the action, and covers purpose, output, side effect, and access requirement without any 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 2-parameter tool with no output schema, the description fully covers what the tool does, how it works (uses saved resume), what it returns, its side effect (saves to account), and an important prerequisite/constraint (paid plan). No gaps.
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 have full descriptions in the schema (100% coverage). The tool description adds no new parameter semantics beyond what the schema already provides, so the baseline 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 a specific verb ('Write') and resource ('cover letter for a specific job'), and notes it uses the saved resume and saves the result. This distinguishes it from siblings like generate_interview_questions and build_pdf, which serve different purposes.
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 clear context for when to use: when generating a tailored cover letter from the saved resume for a specific job. It does not explicitly name alternatives or exclusions, but the context is sufficient to infer appropriate use, earning a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
aiapplyd_generate_interview_questionsGenerate Interview QuestionsAProduce 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable context beyond annotations by stating the account requirement and that STAR scenarios are derived from the job posting, which clarifies the tool's behavior and data source.
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, front-loaded sentence that efficiently lists all deliverable types and the account prerequisite. Every phrase adds value, with no redundant or filler content.
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 thoroughly covers the tool's output sections and prerequisites, which is important given no output schema. However, it leaves ambiguity about how the tool behaves when job_description is omitted (since it's optional but central to STAR scenarios), preventing a perfect score.
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%, with all three parameters fully documented. The description adds slight extra meaning by linking job_description to STAR scenarios ('drawn from the posting') and mentioning 'specific role and company,' but does not substantially expand on the schema's parameter descriptions. Baseline 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 uses a specific verb ('Produce') and identifies the resource ('interview preparation for a specific role and company'). It enumerates distinct output components (company insights, questions, STAR scenarios, etc.), making it clearly distinct from sibling tools like cover letter generation or resume optimization.
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 clearly conveys when to use the tool (preparing for an interview at a specific company/role) and includes a prerequisite (connected AI Applyd account). It does not explicitly name alternatives or exclusions, but the specificity of the output and the sibling tool names imply appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
aiapplyd_optimize_resumeOptimize Resume with AIAInspectRewrite 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 value beyond the annotations by specifying what the tool returns (rewritten resume, ATS score, itemized change summary) and the prerequisite of a connected account. It is consistent with readOnlyHint=false (rewriting implies mutation) and does not contradict 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?
Two concise sentences: the first states purpose and return payload, the second covers parameter usage and prerequisites. Every word earns its place; no redundancy.
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 return values (rewritten resume, ATS score, change summary), the optional job_description, and the account requirement. Given no output schema, it is sufficiently informative, though slightly more detail on the format of the ATS score or change summary could be provided.
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 description's mention of job_description optionality duplicates the schema's 'optional -- omit for general ATS optimization' and adds no new semantic nuance 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 clearly states the tool's action: 'Rewrite a resume so it passes ATS screening,' which specifies the verb and resource. It also distinguishes itself from siblings like aiapplyd_score_resume by focusing on rewriting, not just 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?
It gives clear context on when to use (to rewrite a resume for ATS) and how to tailor it with a job_description, including the option to omit for general optimization. However, it does not explicitly name alternative tools or state when not to use this one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
aiapplyd_score_resumeScore ResumeAScore 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is known. The description adds valuable context about prerequisites ('Requires a connected AI Applyd account and uses the user's credits') and describes the output structure, which goes beyond the annotation-only baseline. No contradiction exists.
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 four sentences, each earning its place: purpose, output details, usage modes, and prerequisites. It is front-loaded with the core action, and all content is directly relevant without redundancy.
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 appropriately explains return values (overall score, section scores, keyword matches/misses, rewrite suggestions). It also covers both operational modes and account/credit prerequisites, making it complete for a two-parameter tool.
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%, with both resume_text and job_description already described in the schema. The description's note about omitting job_description for a general score is redundant with the schema's description. The description adds no new parameter-level meaning, so the baseline of 3 applies.
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 'Score a resume for ATS compatibility,' a specific verb+resource statement. It clearly distinguishes from siblings like aiapplyd_optimize_resume (which modifies) and aiapplyd_analyze_job_description (which analyzes a job posting). The mention of returned score components further clarifies the tool's unique role.
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 clear context on parameter usage: 'Pass job_description to score against a posting, or omit it for a general ATS readiness score.' This helps the agent know which mode to use. However, it does not explicitly mention alternatives or when-not-to-use cases, relying instead on the tool's self-explanatory name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
aiapplyd_search_jobsSearch JobsAReturn 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=true, idempotentHint=true, and destructiveHint=false. The description goes further by specifying exactly what is unaffected ("it never changes which roles AI Applyd hunts for"), adding the account requirement, and describing the return payload (match score, company, location, salary, extracted skills, application URL) — all useful behavioral context beyond 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, front-loaded with the primary purpose. The first sentence covers action and scope, the second clarifies read-only behavior and names the alternative, and the third gives the prerequisite. Every sentence earns its place with zero 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?
Despite having no output schema, the description compensates by listing the fields each match carries. It covers purpose, filters, return content, behavioral guarantees, the related sibling tool, and a prerequisite — complete for a straightforward search/list tool with only three flat parameters.
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 schema already documents all three parameters (job_title, location, remote_only) with examples. The description's phrase "filtered by title, location, and remote preference" maps cleanly to the parameters but adds little new semantic meaning; the schema carries the heavy lifting, which matches the baseline of 3.
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+resource: "Return the user's AI-curated job matches, filtered by title, location, and remote preference." This clearly distinguishes it from siblings like aiapplyd_score_resume or aiapplyd_auto_apply, and it explicitly contrasts with aiapplyd_update_job_preferences, which is the write counterpart.
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 names the alternative tool: "use aiapplyd_update_job_preferences for that" — clarifying when NOT to use this tool. It also states the prerequisite of "a connected AI Applyd account," giving an agent the context needed to decide whether the tool is applicable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
aiapplyd_translate_resumeTranslate ResumeAInspectTranslate 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 adds valuable behavioral context beyond the annotations: it explicitly states "Saves the translation as a new resume and leaves the original unchanged," which tells the agent the side effect and non-destructive nature. It also mentions the authentication requirement ("Requires a connected AI Applyd account"). No contradictions with annotations found.
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 two sentences, front-loaded with the core action, and every phrase adds value. No redundant or filler content.
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 simple single-parameter tool with no output schema and clear annotations, the description fully covers what the tool does, the side effect (creation of a new resume), and a key requirement (connected account). It is complete and sufficient for an agent to select and 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?
Schema coverage is 100% (target_language is fully described with examples), so the baseline is 3. The description mentions "another language" but adds no new syntactic or semantic details about the parameter 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 clearly states the verb and resource: "Translate the resume saved on the user's AI Applyd account into another language." It distinguishes from sibling tools like aiapplyd_optimize_resume or aiapplyd_generate_cover_letter by focusing specifically on translation, and mentions the outcome of being "ready to send to employers in that market."
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 through the phrase "ready to send to employers in that market," indicating a job-application context in a foreign language. It also notes a prerequisite ("Requires a connected AI Applyd account"), but does not explicitly name alternative tools or 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.
aiapplyd_update_job_preferencesUpdate Job PreferencesASet 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 goes beyond annotations by explaining the destructive behavior concretely: it REPLACES saved lists, so the complete list must be provided. It also notes the immediate discovery re-run, adding behavioral context not present in 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 concise sentences: function, critical warning, and usage condition. No wasted words, and the most important information (replacement) 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?
Covers the essential context: what it does, when to use it, the destructive side effect, and the prerequisite. No output schema exists, but for a mutation tool the description is sufficiently complete; minor gaps like return value are not critical.
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 descriptive text (e.g., 'REPLACES the saved list'). The description adds no new parameter-level information beyond repeating the replace advice, so baseline 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 states a specific verb ('set') and resource ('roles and locations AI Applyd hunts for'), clearly distinguishing it from sibling tools like search_jobs or auto_apply. It also mentions the immediate re-run of discovery, which adds scope.
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 explicit when-to-use guidance ('Only call this when the user explicitly asks to change what they are looking for') and a prerequisite (connected account). It does not name alternative tools explicitly, but the exclusion is strong enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!