ResumePilot MCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes, but there is slight overlap between generate_application_profile and prepare_application (both prepare components for applying) and between search_application_emails and update_application_tracking (both can update status). Descriptions clarify boundaries, but a few tools could be confused without careful reading.
Naming Consistency5/5
All tool names follow a consistent verb_noun or verb_preposition_noun pattern using snake_case. Examples like upload_master_resume, analyze_job, get_application_status, and generate_application_report are predictable and follow the same convention throughout.
Tool Count4/5
At 17 tools, the set is slightly heavy but justified by the broad scope of resume management, job analysis, application preparation, tracking, and reporting. Each tool addresses a distinct step in the workflow, though a few could potentially be consolidated without loss of clarity.
Completeness5/5
The tool set covers the full lifecycle from resume upload and profile setup, through job analysis and optimization, to application preparation, submission (manual), tracking, email search, and reporting. No critical steps are missing; the only limitation (e.g., no delete or edit for resume) is intentional due to immutability.
Average 3.7/5 across 17 of 17 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- Last stable release on August 24, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full burden of behavioral disclosure. The description implies a read-only operation ('Return'), but it does not explicitly state that there are no side effects, no permission requirements, or any limitations (e.g., pagination, sorting, or error behavior). Without annotations, this level of transparency is insufficient for a tool that could be expected to have subtle behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the action and output. There is no redundant information, filler, or repetition of the tool name. Every word contributes to understanding the tool's purpose, making it highly concise and well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers the core functionality (status, scores, timeline, single vs. all). However, it lacks context on usage scenarios, prerequisites, or what constitutes a 'status' or 'scores' in the domain. Given the absence of annotations and output schema, a bit more detail would improve completeness, but the current level is justifiable for a straightforward retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines an optional integer with exclusiveMinimum:0, providing zero descriptive coverage. The description compensates partially by explaining that the parameter is a 'number' used to select a single application, and that omitting it returns all applications. This adds meaning beyond the schema, but it does not specify what the number represents (e.g., application ID) or clarify edge cases like an invalid number. Given the low schema coverage, the description is adequate but not thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Return') and resource ('status, scores and timeline of one application or all applications'). It specifies what is returned and distinguishes between single and all instances via the optional parameter. However, it does not explicitly compare to sibling tools like generate_application_report or update_application_tracking, so differentiation relies on inference from the stated output rather than direct naming.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only explains what the tool does, not the conditions that would make it the appropriate choice among siblings such as generate_application_report or update_application_tracking. An agent is left to infer usage context from the tool's name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states it 'Return' data, implying a read-only operation, but does not explicitly say it has no side effects, requires no authentication, or what happens if the profile is incomplete. The mention of 'still-missing fields' hints at returned status but is minimal. No error conditions or output format are described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core action and key output. It is concise with no wasted words. However, it may be too brief for a tool with no output schema, but for a simple getter it is appropriately compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description should explain the return structure and key concepts. It mentions 'Master Profile' and 'still-missing fields' but does not elaborate on what these contain or how they are represented. It also lacks usage context and alternatives, which a zero-param tool with no schema could benefit from. It is minimally sufficient but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, and since schema coverage is trivially 100%, there is no gap. The description adds no parameter-specific meaning, which is acceptable for a param-free tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the current Master Profile and lists missing fields. The verb 'Return' and resource 'Master Profile' make the purpose specific and distinguish it from setup/update tools that modify profiles. However, it doesn't explicitly differentiate from siblings like analyze_master_resume, but the intent is evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical scenarios, or exclusions. With 16 siblings, an agent would have to infer that this is for reading the profile, but nothing states when to call it over update_user_profile or setup_user_profile.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states that it generates files and returns paths, but does not mention whether the operation is read-only, whether it overwrites existing files, what data it depends on, or any side effects. This is a gap for a tool that creates artifacts on disk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loaded with the primary output (PDF report) followed by the secondary output (HTML tracking pages). It includes the return value and avoids any unnecessary wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one boolean parameter, the description covers the output and return value. However, it omits the parameter's meaning and any behavioral transparency (side effects, prerequisites). Given no annotations, the description should have provided more context for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single boolean parameter 'includeTrackingPages' with a default of true, but the description does not mention this parameter or explain its effect. With 0% schema description coverage, the description should have described the parameter to help the agent decide whether to override it. The meaning is not self-evident from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it generates a professional PDF report (summary stats + application table + per-application detail sections) and local HTML tracking pages. It clearly distinguishes from sibling tools that focus on other actions like searching, analyzing, or applying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. Among the listed siblings, this is the only report generation tool, making its usage implied, but there is no explicit guidance on prerequisites or scenarios where it should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden. It clearly discloses the side effect of updating application tracking, the read-only nature of the Gmail connection via OAuth, and that no passwords are stored. It also explains the status classification. This is strong transparency, though it stops short of describing error behaviors or edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action, then lists the classification and side effect, and finally provider details. It is efficiently written without excess, though the phase info could be separated more clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (search, classify, update), 4 parameters, no output schema, and no annotations, the description provides enough to invoke it (application ID is required, optional filters are listed) but omits the return value format and any error handling expectations. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only 'since' has a description). The description mentions search by company, role, recruiter email, or domain, but the schema only includes 'domain' and 'recruiterEmail'—company and role are absent. It does not clarify the meaning of 'application' (required) or 'domain' beyond the name. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search') and resource ('connected email provider'), and details the actions: classify into statuses and update tracking. It is distinguishable from siblings like get_application_status (read-only) and update_application_tracking (direct update) because it explicitly includes search and classification, but it does not name any sibling as an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context about provider phases (mock vs. Gmail) but does not explicitly state when to use this tool versus alternatives like search_jobs or get_application_status. It implies usage for searching and classifying application-related emails, but lacks explicit when-not or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It partially discloses behavior by stating it returns 'the planned configuration and which sources could serve the query' and mentions JOB_SEARCH_MAX_JOBS and JOB_SEARCH_CONCURRENCY as constraints. However, it remains ambiguous whether it actually executes a search when sources are connected, and the main verb 'Search' may mislead. This is a partial disclosure, not a full one.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loads the primary purpose, then gives the Phase 1 caveat and return behavior. It avoids redundancy, though the technical phrasing about JOB_SEARCH_MAX_JOBS and concurrency could be clearer. Overall, it is compact and well-ordered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 optional parameters, no output schema, and no annotations, the description is incomplete. It explains the return type (planned configuration and sources) but does not cover parameter meanings, the actual search execution behavior, or what constitutes 'connected sources'. Essential details for correctly invoking the tool are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no information about any of the five parameters (limit, roles, keywords, workMode, locations). It doesn't explain their meaning, purpose, or how they affect the search. The description fails to compensate for the schema gap, leaving agents to guess parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search connected job sources for relevant jobs' – a specific verb and resource. It also distinguishes itself from analyze_job by explicitly directing users to 'paste a job description into analyze_job instead' in Phase 1, making the tool's scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit when-not and alternative: 'In Phase 1 no automated search source is connected yet — paste a job description into analyze_job instead.' However, it only implies the positive condition (when connected sources exist) rather than stating it directly, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal that status changes are timestamped and that an email can be attached, which are useful non-obvious details. However, it does not mention side effects on existing data, whether the note field interacts with updates, or any required permissions. The transparency is partial, so a score of 3 is warranted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences with no superfluous wording. The first sentence front-loads the primary action, and the second adds typical use cases. It is efficient, though the omission of the note parameter could be seen as a missed opportunity, but that is a completeness issue rather than a conciseness flaw.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, a nested email object, no output schema, and no annotations), the description is too sparse. It fails to explain the note field, the email object's subfields, the required application parameter, and the behavior when both status and email are supplied. An agent would lack crucial information to call this tool correctly, so contextual completeness is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since the input schema has no property descriptions (coverage 0%), the description must explain parameter meaning. It covers the 'status' parameter ('set a new status') and the 'email' parameter ('attach an email update'), but it completely omits the 'note' parameter and fails to clarify that 'application' is an identifier. The structure of the nested email object is also left unexplained. Half the parameters are undocumented, so the description does not sufficiently compensate for the missing schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: manually update an application's tracking by setting a new status and/or attaching an email. It also lists common use cases (interviews, offers, rejections, withdrawals) which helps distinguish it from sibling tools like get_application_status (read-only) and apply_to_job (automated). The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool by listing typical recording scenarios, but it does not explicitly mention alternatives or exclusion criteria. It does not clarify that this is for manual updates only, nor does it contrast with automatic processes. The guidance is adequate but lacks explicit boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral disclosure. It mentions 'flag which clear the MATCH_SCORE_THRESHOLD' but does not clarify whether this flag is a returned field or a persisted modification to stored data. It also does not indicate if the operation is read-only or if it has side effects, leaving ambiguity about its actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. The main action and key criterion (match score, ATS tiebreaker, threshold) are front-loaded, and every part adds value. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and no output schema or annotations, the description covers the core purpose but omits important context such as the output format (e.g., what a flagged application looks like), potential side effects, or prerequisites beyond having analyzed applications. It is minimally adequate but leaves gaps an agent might need to resolve.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single optional parameter 'threshold' with 0% description coverage. The description references MATCH_SCORE_THRESHOLD, which likely corresponds to the threshold parameter, but does not explicitly state that the parameter overrides the default threshold. This is implied but not clearly explained, so it partially compensates for the schema gap but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (rank), the object (analyzed applications), the criteria (overall match score with ATS tiebreaker), and the outcome (flagging those above the threshold). This distinguishes it from siblings like analyze_job (single job analysis) and search_jobs (job discovery).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it operates on already-analyzed applications, which suggests a sequence (analyze first, then rank). However, it does not explicitly state when to use or not use it relative to specific alternative tools, such as 'use analyze_job before this' or 'this is not for searching jobs.' The context is clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It does disclose an important trait: 'The original is stored immutably and never modified.' However, it omits critical behavioral details such as whether an existing master resume is overwritten, how duplicate uploads are handled, authentication/permission requirements, or any side effects. Given the write nature, more transparency would be expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, perfectly concise, and front-loaded with the primary purpose. Every word adds value — formats, input options, and the immutability guarantee. There is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, so the description covers the basics: purpose, input options, and a key behavior. However, it leaves gaps: it doesn't specify what happens if both 'path' and 'text' are provided, whether it returns a success indicator or ID, or how it handles existing uploads. Given there is no output schema, a small note on expected return would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are already fully described in the schema. The description adds only marginal value: it marks 'path' as preferred and clarifies the file is on the user's machine, which is hinted at in the schema's 'Absolute local path'. This is helpful but does not significantly extend the schema semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Register') and a clear resource ('the user's ONE master resume'), and enumerates accepted formats (PDF, DOCX, TXT, Markdown). It unambiguously conveys the tool's action and distinguishes it from siblings like analyze_master_resume by focusing on registration/upload rather than analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives parameter usage guidance ('Provide either a local file path (preferred) or raw text') but does not explicitly address when to use this tool versus alternatives or when not to use it (e.g., if a resume already exists). The 'preferred' note for path is helpful, but no exclusionary context or alternative routing is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and it answers key behavioral questions: it states which fields are autofilled (verified master profile, known answers), which must come from the user, and that it never guesses, especially for legal/declaration answers. This is an explicit behavioral commitment that adds real value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one efficient sentence that front-loads the primary purpose before listing components. It packs substantial detail without excessive verbosity, though it could be trimmed slightly without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool being relatively simple (one parameter, no output schema), the description fails to explain the parameter or the exact structure of the generated profile. With no annotations or output schema, the description should have covered these basics; it does not, leaving notable gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single required parameter 'application' is not explained at all in the description. With schema description coverage at 0%, the description was expected to compensate but instead ignores the parameter entirely. An agent is left to guess that 'application' refers to an application ID based solely on the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Build') and resource ('job-specific application profile'), and details exactly what the profile contains (autofillable fields, known answers, user-required questions). It clearly distinguishes itself from siblings like analyze_master_resume or prepare_application by focusing on the job-specific profile derived from the verified master profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when this tool is used: to construct the application profile from verified data, separating it from other steps. However, it does not explicitly state when NOT to use it or mention alternative tools, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It transparently discloses that the tool does not auto-submit to external sites, sets the application to READY_TO_APPLY, and lists human-only steps (login, CAPTCHA, etc.). This gives the agent a clear picture of side effects. It doesn't mention any requirements (e.g., existing job, resume), but the main behavior is well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with high information density, front-loaded with the main purpose. It lists the key outputs and the safety guarantee without redundant phrasing. Everything earns its place, making it an excellent example of concise, effective description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the behavioral outcome (preparation, no submission, status set, human steps listed) comprehensively. However, it lacks any explanation of the input parameter, and since there is no output schema, the return value is unaddressed. For a tool with a single integer parameter, the missing parameter semantics is a notable gap, but the behavioral context is strong. Overall, it's adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it fails to explain the sole parameter 'application' (an integer). The description never mentions that the parameter is an application ID or what values are valid. Without this, an agent cannot correctly determine what to pass. This is a significant omission in a tool with only one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('prepare') and resource ('application'), and enumerates concrete deliverables (autofill map, customized resume, manual checklist). It also explicitly differentiates from the sibling 'apply_to_job' by clarifying that nothing is auto-submitted in Phase 1, making the distinction between preparation and submission clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: it's the preparation step before submission, contrasted with 'apply_to_job' which presumably handles submission. The phrase 'In Phase 1 nothing is auto-submitted' signals when to use it, but it doesn't explicitly name alternatives or give a 'when not to use' condition. The guidance is clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it does an excellent job. It discloses that the tool never auto-submits externally, returns PAUSED_FOR_USER with a checklist, and only records APPLIED when markApplied is explicitly passed after user confirmation. This is concrete, non-obvious behavioral information beyond the tool name and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the main action appears first, followed by the key behavioral caveat and the conditional flag instruction. Every sentence contributes essential information, and there is no filler or repetition of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the outcome states and the critical user-confirmation condition, which is valuable for a tool with no output schema and no annotations. However, it omits what `application` refers to (likely an application ID from a previous step), what `note` does, and any fallback or error behavior. Enough to invoke the tool at a basic level, but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description should compensate for the undocumented application and note parameters, but it only explains markApplied. The `application` integer and `note` string are never described, leaving the agent without enough semantic context to populate them correctly. markApplied gains slight additional meaning ('record it as APPLIED'), but the other two parameters remain under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('submit the application') and the mechanism ('through the resolved application adapter'), so the tool's core purpose is unambiguous. It does not explicitly name or differentiate siblings like prepare_application or update_application_tracking, but the intent is still distinct enough for an agent to identify 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear operational guidance: in Phase 1, the manual adapter never auto-submits, and markApplied should be true only after user confirmation. This tells the agent when and how to use the tool effectively, though it does not explicitly discuss alternatives or when to prefer another sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Same merge semantics as setup_user_profile' hints at partial updates, but does not explain what that means in practice (e.g., whether arrays replace or merge, if nested objects are deep-merged). It does not disclose return values, error conditions, or any side effects. This is insufficient for a write operation without any annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences total, with the primary action front-loaded and examples kept brief. Every sentence contributes to understanding: the merge reference prevents misuse, and the usage examples ground the abstract 'updates' map. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does not explain what the tool returns (e.g., the updated profile). It also relies on the agent understanding `setup_user_profile`'s merge semantics without elaboration. For a single-parameter mutation tool, this is acceptable but leaves gaps around response formatting and edge cases (e.g., empty updates object).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a minimal description ('Map of field -> new value'). The tool description adds valuable context by listing typical fields (preferredLocations, relocationPreference, reusable application answers) and clarifying the merge behavior, which helps agents infer acceptable values beyond the generic schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the action ('Update') and resource ('specific Master Profile fields') precisely. It immediately disambiguates from the sibling `setup_user_profile` by referencing the same merge semantics, so the agent understands this is a partial update, not initial creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases: 'corrections or adding preferences' with concrete field examples. It implicitly distinguishes from `setup_user_profile` by referencing it, though it does not explicitly state 'use setup_user_profile for initial setup'. Context is clear, but the exclusion is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a key behavioral trait: 'ResumePilot never stores passwords or OTPs' — a security guarantee. It also clarifies that external adapters connect via official login/OAuth in later phases. However, it does not state what happens when 'connect' is invoked (e.g., OAuth flow initiation) or whether it modifies state beyond the connection itself. Still, the security note and phase context provide significant transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and source types, then adds contextual details about phase availability and security. Every word earns its place; no fluff. It is concise yet informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema, no annotations), the description covers essential context: what sources exist, current availability, and security behavior. It could mention what the tool returns (e.g., a list of sources or connection status), but the omission is minor given the 'inspect or list' nature. Overall, it is adequately complete for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 the parameter ('Adapter id to connect (e.g. 'manual'). Omit to list all sources.'). The tool description reinforces this by mentioning 'manual' and the omission behavior, but adds minimal new meaning. Since the schema covers the parameter semantics fully, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Inspect or connect a job source adapter' and lists specific source types (professional networks, job boards, career pages, APIs, ATS pages). It also distinguishes the current phase (manual source ready) from future phases, which helps an agent understand the scope. This differentiates it from siblings like search_jobs or apply_to_job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context about when to use the tool ('Phase 1 has the `manual` source ready') and notes that real adapters come later, implying current usage is limited to manual source. However, it does not explicitly guide the agent on when to choose this tool over alternatives, nor does it mention exclusions. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behavioral traits: it creates a tracked application, returns its number, computes ORIGINAL scores, and avoids inventing unverifiable requirements. It does not however describe error behavior when the master resume/profile is absent or what exactly happens to previous analysis data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main purpose, then outputs, side effect, and next step. Every sentence adds a distinct piece of useful information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, side effects, and the returned application number, which is enough to invoke the tool. Without an output schema, it leaves the full response shape of scores and extracted data implicit, and it assumes the master resume and profile already exist without stating that prerequisite.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 40%, so the description had to compensate for undocumented parameters. It highlights pasting the description but adds no guidance for title, company, location, or url beyond their obvious names, and does not explain how optional metadata affects the analysis.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific action ('analyze it against the master resume + profile') and enumerates concrete outputs: extraction, ATS/match scores, missing keywords, buried experience, weak bullets, and unverifiable requirements. It also distinguishes itself from siblings by naming the next step (optimize_resume_for_job) and by targeting job analysis rather than resume analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes this as 'Phase 1' and explicitly says to follow with optimize_resume_for_job, giving clear workflow sequencing. It does not explicitly state when to prefer analyze_master_resume or to first upload/setup the master resume/profile, so exclusion guidance is incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It discloses the core behavioral guarantee (uses only genuinely present information, never invents), the output format (PDF + DOCX), and the return values (ATS scores, changes, unverified requirements). It does not mention whether the tool mutates the application tracking state, but this is likely handled by sibling tools; overall, the description covers the most critical behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the primary purpose, then flows through actions, constraints, and outputs. Every sentence adds value, with no redundant phrasing. It is concise yet comprehensive, a model of efficient writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two parameters and no output schema, the description covers everything an agent needs: what it does, prerequisites (tracked application, master resume), output format, and return data. It even specifies constraints on information sourcing. The lack of an output schema is mitigated by explicitly listing the returned artifacts. This is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema (application and targetScore) with clear descriptions. The tool description adds context that ties targetScore to ATS scoring but does not provide additional syntax or usage details beyond what the schema already states. With 100% schema coverage, the description meets the baseline but adds no extra parameter-level semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair: 'Generate a job-specific tailored resume for a tracked application.' It then lists concrete actions (surfaces keywords, reorders skills/bullets, adds summary) and explicitly states what it does NOT do (never invents information). This clearly distinguishes it from generic resume tools and even from sibling tools like generate_application_profile, which likely focus on other outputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it requires a 'tracked application' and uses information from the master resume/profile, implying that analyze_job and upload_master_resume must have been run first. However, it does not name any alternative tools or state when not to use it, leaving some ambiguity about its relationship to generate_application_profile or prepare_application.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states key behaviors: only fills provided fields, never overwrites with blanks, and never asks twice. It does not mention side effects, error handling, or what happens if the answers object is empty, but the core behavior is disclosed adequately for a merge operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with no redundant wording. It front-loads the main action and provides a useful example inline. The style is efficient, though it could be structured into clearer sentences, but it earns a high score for precision and lack of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested object parameter) and the absence of an output schema and annotations, the description covers the essential use case, key behavior overrides, and accepted input format. It does not explain error cases or what the tool returns, but those are likely not critical for a merge operation. It is sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers 100% of the parameters, but the description adds significant value by listing example field names and noting that comma-separated strings are accepted for list fields (as also in schema). This helps the agent construct valid answers without needing to inspect the schema. It goes beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Apply the user's answers'), the resource ('missing-information questionnaire' merged into 'Master Profile'), and provides a concrete example of the expected keys. It distinguishes itself from sibling tools like update_user_profile by explicitly tying it to the questionnaire and the 'never asks twice' behavior, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use it (when answers to the missing-information questionnaire are available) and what it does (merges answers, fills provided fields). It does not explicitly name alternatives like update_user_profile or state when not to use it, but the context of the questionnaire is clear enough for an agent to select the right tool among the many profile-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that it parses, builds a draft, and returns missing fields, and explicitly states 'Nothing is invented' – a transparency guarantee. It does not mention side effects or full return format, but for a read-like operation this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, with the core action front-loaded. The 'Nothing is invented' note is a valuable behavioral guarantee in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description explains what it does and its key output (missing fields). It implicitly relies on the stored resume without explicitly stating the prerequisite, but the workflow context from siblings covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so baseline is 4. Description adds no parameter-specific info as none exist, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: parse the stored master resume, build a draft Master Profile, and return missing fields. It distinguishes itself from siblings like upload_master_resume (which uploads) and get_user_profile (which retrieves existing profile) by focusing on analysis and drafting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used after a resume has been uploaded and when a draft profile needs to be built. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to determine its use case. Sibling context reinforces the workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![auto-apply-resume-pilot MCP server](https://glama.ai/mcp/servers/rajeshaipython-stack/auto-apply-resume-pilot/badges/card.svg)](https://glama.ai/mcp/servers/rajeshaipython-stack/auto-apply-resume-pilot)

Score Badge

Copy to your README.md:

[![auto-apply-resume-pilot MCP server](https://glama.ai/mcp/servers/rajeshaipython-stack/auto-apply-resume-pilot/badges/score.svg)](https://glama.ai/mcp/servers/rajeshaipython-stack/auto-apply-resume-pilot)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rajeshaipython-stack/auto-apply-resume-pilot'

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