ATS resume scoring, job analysis, interview prep, and auto-apply that verifies each submission.
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?
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.
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?
Annotations already flag destructive and not-idempotent behavior, and the description adds substantial context on top: it actually rewrites documents, submits the form on the employer's ATS, and either submits directly or routes to a review queue based on account settings. It also discloses the paid-plan prerequisite, a behavioral constraint not available in schema or 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 pack the core action, supported ATS platforms, review behavior, and pricing constraint without redundancy. The platform list is long but earns its place because compatibility is a valid decision input for the agent.
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 destructive, externally visible action with one input parameter, the description covers what will happen, where it happens, which platforms are supported, how review settings affect submission, and the required paid plan. Return values are not described, but no output schema exists and the agent has enough to select and 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?
The single parameter job_url has a schema description, and the tool description adds useful selection semantics by emphasizing 'ONE specific job posting' and 'not a job board'. This tells the agent to pass a direct employer ATS posting URL rather than an aggregator link, which the schema alone does not convey.
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?
Opens with 'Apply to ONE specific job posting end to end', a specific verb and resource, and immediately distinguishes itself from sibling component-tools by covering the whole pipeline from rewriting to submission on the employer's own hiring system. The ATS list and review-queue behavior further pin down exactly what this tool does.
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 makes clear the tool is for applying to a single specific posting and not to a job-board listing, so an agent knows the right input context. It does not explicitly name sibling tools or say 'use X instead when you only want a cover letter/resume', but the scope is unambiguous enough for invocation.
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?
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.
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?
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.
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?
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.
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 behavioral context beyond annotations: it reveals the three return components (rewritten resume, projected ATS score, itemized change summary) and the connected-account requirement. Annotations already indicate a non-read-only mutation, so the description meaningfully supplements them without 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?
Three sentences, all information-dense: main purpose and return values first, then optional-parameter behavior, then prerequisite. No filler or repetition of schema 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?
With no output schema, the description appropriately explains what the tool returns. It also covers the optional parameter behavior and requirement for a connected account. It could be slightly stronger by distinguishing itself from sibling tools, but nothing critical is missing for a correct call.
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 both parameters. The description adds value by explaining the conditional semantics of job_description: include it for a tailored rewrite or omit it for general optimization.
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 specifies a clear verb and resource: 'Rewrite a resume so it passes ATS screening.' It also differentiates from siblings like aiapplyd_score_resume by stating it returns a rewritten resume plus an itemized change summary, not just a score.
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 conditional guidance: pass job_description to tailor to a specific posting, or omit it for general ATS optimization. It also states the account prerequisite. It does not explicitly name sibling alternatives, but the usage context 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?
Beyond the readOnly/destructive annotations, the description discloses meaningful operational behavior: it requires a connected AI Applyd account and consumes the user's credits. It also describes the return payload since no output schema exists. 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, each earning its place: purpose and outputs, then parameter guidance, then prerequisites. Information is front-loaded and no filler is present.
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 two-param, no-output-schema scoring tool, the description supplies all essential context: what it does, what it returns, how to vary behavior, and what account/cost prerequisities apply. Nothing needed for correct invocation 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%, so the baseline is 3. The description adds real value by explaining the semantic effect of including vs. omitting job_description, which the schema only labels as optional. resume_text needs no extra explanation beyond 'Full text of the resume.'
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 clear verb-resource pair: 'Score a resume for ATS compatibilty.' It also enumerates the concrete outputs (overarch score, section scores, matching/missing keywords, rewrite suggestions), which distinguishes it from sibling tools like optimize_resume or analyze_job_description. The optional job_description use case furter clarifies its exact 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 provides actionable param-level guidance: pass job_description to score against a posting, or omit it for a general ATS readiness score. It does not explicitly compare itself to alternatives or state when not to use it, but the context is clear enough for an agent to decide.
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=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.
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 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.
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 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
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_resumeClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Auto-apply to jobs: matches your CV, tailors a fresh CV per posting, and applies for you.
Analyze job listings against your resume, track applications, and generate cover letters.
Tailored, graded job applications: a CV, cover letter and form answers built per vacancy.
Search jobs, tailor your resume, write cover letters, and file applications for you.
Add one secure layer between your agents and this server.
Each tool maps cleanly to a distinct job-search action: analyze a posting, apply, build/optimize/score/translate resumes, generate cover letters/interview prep, search jobs, and update preferences. The only adjacent pair, score_resume and optimize_resume, is clearly separated by assessment versus rewrite.
All tools share a consistent aiapplyd_ prefix and follow an actionable verb_noun pattern: analyze_job_description, generate_cover_letter, score_resume, update_job_preferences. No style mixing or vague generic names are present.
Ten tools is well-scoped for a job-application assistant, covering the main user journeys without redundancy or bloat. Each tool has a clear, non-overlapping responsibility.
The tool surface covers the core lifecycle: preferences, job search, resume analysis and optimization, PDF generation, cover letters, auto-apply, and interview prep. Minor gaps exist around listing saved resumes/cover letters and tracking submitted applications, but these are workable via the connected account.
