JobPilot MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Tools have distinct purposes overall, but auto_apply, indeed_apply, and linkedin_apply have overlapping functionality. Descriptions help differentiate, but an agent might still be confused about which apply tool to use.
Naming Consistency4/5
Tool names follow a mostly consistent snake_case pattern with imperative verbs. Minor deviations like 'indeed_apply' vs 'auto_apply' exist, but overall pattern is readable and predictable.
Tool Count5/5
11 tools is well-scoped for a job application automation server. Each tool serves a necessary function without unnecessary redundancy.
Completeness4/5
The tool set covers the main job application workflow, but missing a tool to list or retrieve existing applications from Notion. This is a minor gap that agents could work around.
Average 3.7/5 across 11 of 11 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
No annotations are present, so the description carries full burden. It does not disclose behavioral traits such as that it is a write operation, requires authentication, or how it handles duplicates. 'Full details' is vague.
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 sentence, which is concise. For a tool with 8 parameters, it could be slightly longer but is not overly verbose.
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 has 8 parameters, 4 required, no output schema, and no annotations, the description is insufficient. It does not explain return values, error handling, or the need for prior setup (sibling 'setup_notion_db' hints at this).
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?
With 63% schema description coverage, the description adds no meaning beyond the schema. It does not explain how parameters map to the Notion database fields or that it inserts a new row. The phrase 'full details' does not compensate.
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 'Log a job application to the Notion Job Tracker database with full details' clearly specifies the verb (log) and the resource (job application to Notion database). It is distinct from sibling 'update_application_status' which implies modifying existing records, though it could explicitly state that it creates a new entry.
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 like 'update_application_status'. The description lacks any context about prerequisites or scenarios for use.
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 disclose behavioral traits. It states the tool generates a letter but does not mention whether it saves data, modifies anything, or requires specific permissions. The output format is not described, leaving uncertainty about the tool's behavior beyond generation.
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 concise sentence with no unnecessary wording. It is front-loaded with the key action. However, it is very brief and could include more detail without losing conciseness.
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?
The tool has nested objects and no output schema. The description does not explain what the return value is (e.g., a string of the cover letter) or any constraints on the input objects. For a moderately complex tool, this is insufficient to fully guide an agent.
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 the input schema already documents all parameters. The description adds no extra meaning beyond the schema's descriptions of 'candidate_profile', 'job', and 'tone'. The baseline of 3 is appropriate since the schema carries the semantic load.
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 identifies the tool's function: generating a cover letter for a specific job based on a candidate profile. The verb 'generate' and resource 'cover letter' are specific. However, it does not differentiate from sibling tools like 'generate_follow_up' or 'auto_apply', which have distinct purposes.
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 implies usage when a cover letter is needed, but it lacks explicit context on when to use this tool versus alternatives. No exclusions or alternatives are mentioned, making the guidance adequate but minimal.
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. It only states 'Update the status' without disclosing any behavioral traits such as validation, side effects, or required permissions. The lack of detail is insufficient for a mutation tool.
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 sentence that concisely states the action and resource with an example. No extraneous words or redundancy.
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 has 3 parameters, no output schema, and no annotations, the description is too brief. It does not address return values, error conditions, or what happens on a successful update. More context is needed for a write operation.
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% (only notion_page_id has a description). The description adds no parameter-level detail beyond the schema's enum for new_status and does not explain the optional notes parameter. It 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates the status of an existing job application in Notion, with an explicit example transition. It is distinct from sibling tools which cover applying, logging, parsing, etc.
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 on when to use this tool versus alternatives. The description does not mention prerequisites, when not to use it, or compare with siblings like log_to_notion which might also affect Notion records.
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 disclose behavioral traits. It only states the tool generates an email, but fails to mention whether it sends it, the output format, or any side effects. This leaves significant ambiguity for the agent.
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 with no wasted words. However, it lacks structure (e.g., separating purpose from behavior). It is concise but minimally adequate.
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 has 5 parameters, no output schema, and no annotations, the description is incomplete. It does not explain what the tool returns (e.g., email text, draft), nor does it clarify parameter details beyond the schema. The agent would need to infer or experiment.
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?
With only 20% schema coverage (only application_id has a description), the description does not add meaning to parameters like days_since_applied or candidate_name. It does not compensate for the low schema coverage, leaving parameter semantics unclear.
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 generates a follow-up email for an application without a response. It uses a specific verb ('generate') and resource ('follow-up email'), and distinguishes from sibling tools like auto_apply or generate_cover_letter, which have different purposes.
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 implies usage for applications lacking a response, but provides no explicit guidance on when to use versus alternatives, nor any 'when not to use' or prerequisite conditions. This is minimal guidance.
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 full behavioral burden. It mentions handling PDF path or raw text and extracting fields, but does not disclose error behavior (e.g., invalid file path), performance characteristics, rate limits, or whether the operation is read-only. Essential behavioral details are missing.
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, front-loaded sentence that efficiently conveys the tool's function and output. Every word adds value, with no redundancy or unnecessary information.
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 (2 parameters, no output schema, no annotations), the description provides enough context for basic usage. It explains inputs and outputs. However, it could be more complete by specifying that exactly one of the two parameters is required and by mentioning error handling.
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 baseline is 3. The description adds context ('PDF path or raw text') but does not significantly enhance parameter understanding beyond the schema's descriptions. Both parameters are already well-documented in the schema.
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: 'Parse a CV/resume (PDF path or raw text) and extract a structured candidate profile.' It specifies the verb (Parse), resource (CV/resume), and output fields (name, skills, etc.). Additionally, it distinguishes itself from sibling tools, none of which parse CVs.
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 implies usage: use this tool to extract structured data from a CV. However, it does not explicitly state when not to use it, nor does it mention alternative tools (e.g., score_job_fit might also process CVs). The guidance is adequate but lacks exclusion criteria.
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?
The description discloses use of browser automation (Playwright) and logging to Notion, and mentions the dry_run parameter skips submission. However, it lacks disclosure of potential side effects like state changes from applications, time consumption, rate limits, or authorization needs. With no annotations, the description carries the full burden but is only partly transparent.
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 two sentences that front-load purpose and key behaviors. It is concise without being terse, though it could be more structured (e.g., listing steps). Every sentence adds value.
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 does not explain what the tool returns (no output schema), nor does it specify the job source (assumes remote jobs from some search). For a complex tool with 6 parameters, this is a notable gap. It partially compensates by mentioning Notion logging.
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%, but the description adds valuable context beyond schema: it explains that candidate_profile should come from parse_cv, dry_run skips submission, and min_fit_score/max_applications govern behavior. This enhances parameter understanding.
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 uses specific verbs ('Automatically search, score, generate cover letters, and apply') and a clear resource ('N remote jobs matching the candidate profile'). It clearly distinguishes itself from sibling tools like search_jobs, score_job_fit, and generate_cover_letter by being a composite end-to-end pipeline.
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?
While the description implies this tool is for full automation, it does not explicitly state when to use it versus using the individual sibling tools (e.g., search_jobs, score_job_fit, indeed_apply). No when-not or alternative guidance is provided.
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. It discloses the persistent browser session and login requirement, and describes the output fields. However, it omits potential behavioral issues like rate limits, risk of detection, or that it only works for 'Easily Apply' jobs. This is adequate but not comprehensive.
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 three sentences, front-loaded with the core function, then behavioral detail, then output description. No wasted words; every sentence adds value. 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 complexity (12 parameters, no output schema), the description covers the main workflow and output. It explains the browser session lifecycle and what results include. However, it could be more complete by explaining how dry_run affects other parameters or error handling. It is mostly complete but has minor gaps.
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 all 12 parameters have descriptions in the schema. The description does not add significant new meaning beyond the schema. It hints that candidate_profile comes from parse_cv, which adds context, but overall the parameters are sufficiently documented in the schema. Baseline score 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 searches Indeed and auto-applies using Indeed's native 'Easily Apply' flow. The verb 'search' and 'auto-apply' combined with specific resource 'Indeed' makes the purpose explicit. It distinguishes itself from siblings like 'linkedin_apply' (different platform) and 'auto_apply' (general vs platform-specific).
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's for Indeed's 'Easily Apply' flow, mentions the persistent browser session and first-time manual login. However, it does not explicitly state when NOT to use this tool (e.g., if the job doesn't have Easily Apply) or mention alternatives like 'search_jobs' for broader searching. The usage is implied but lacks explicit exclusions.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool searches multiple platforms and uses a role keyword with optional filters. However, it does not mention behavioral details such as data freshness, rate limits, or what happens if no results are found.
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, well-structured sentence that conveys all essential information without any extraneous words. It is front-loaded with the main action and specifies the platforms and filters.
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 (3 parameters, 100% schema coverage, no output schema, no nested objects), the description is complete enough. It explains what the tool does and on which platforms. However, it could briefly mention the return format or that results are blended from multiple boards.
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 100% coverage for all three parameters, so the baseline is 3. The description adds minimal value beyond the schema, merely stating that the tool uses a role keyword and optional filters. It does not elaborate on parameter constraints or formatting.
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 it searches for open job listings on three specific platforms (RemoteOK, We Work Remotely, Himalayas) using a role keyword and optional filters. The verb 'search' and resource 'open job listings' are explicit, and the tool is well-distinguished from sibling tools that focus on applying or generating letters.
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 for finding jobs based on keywords and filters. While it does not explicitly state when not to use or mention alternatives, the sibling tools are clearly different in purpose (e.g., auto_apply, generate_cover_letter), so the context is clear.
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 persistent browser session, manual login first time, and returns confirmed flag, confidence, message, and screenshot path. It does not mention potential failure modes or rate limits, but covers key behavioral aspects.
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 three sentences, well-structured, and front-loaded with the main action. Every sentence adds value: purpose, session behavior, and return details. No wordiness.
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 explains the return value (confirmed flag, confidence, message, screenshot path) despite no output schema. Parameters are well-documented in schema. It could mention what happens if no jobs are found or fallback behavior, but overall it is sufficiently complete.
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 the baseline is 3. The tool description adds no extra parameter information beyond what is already in the input schema. It mentions filters like 'remote' and 'dry_run' but does not provide additional semantic detail.
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 searches LinkedIn jobs and auto-applies using Easy Apply. It distinguishes itself from siblings like 'search_jobs' (search only) and 'indeed_apply' (different platform). The verb 'auto-apply' and resource 'LinkedIn jobs with Easy Apply' are specific.
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 the first-run login process and reuse of the browser session, providing context on when to use. However, it does not explicitly state when not to use this tool versus alternatives like 'auto_apply' or 'search_jobs'. Still, the usage scenario is clear enough.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns a numeric score, matched/missing skills, and a recommendation. This is sufficient for a read-only scoring tool, though it doesn't explicitly state that no mutations occur.
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 redundant information. The first sentence states the core purpose and output range; the second lists return fields. Every word earns its place.
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?
With no output schema, the description adequately covers what is returned. For a simple scoring tool, it provides sufficient context about inputs (parsed CV, job object) and outputs. Minor gap: no explanation of how to interpret the recommendation.
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 clear descriptions. The description adds value by noting that candidate_profile comes from parse_cv, providing cross-tool context. This goes beyond what the schema alone offers.
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 uses a specific verb ('Score'), identifies the resource ('candidate profile matches a job listing'), specifies the output range (0–100), and lists return items. This clearly distinguishes it from sibling tools like auto_apply or generate_cover_letter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use after parse_cv and before applying, but it does not explicitly state when to use it over alternatives or provide a when-not scenario. Sibling tools are listed but not contrasted.
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 idempotency (skips if already set) and that it creates the DB with correct schema. It does not cover potential errors or side effects, but the key behaviors are transparent.
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. The important action and prerequisite are front-loaded. Very concise and clear.
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 no annotations or output schema, the description covers the essential purpose, behavior, and usage. It lacks details on error handling or the exact schema, but these are minor gaps.
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 already covers the parameter with 100% coverage. The description adds value by advising to 'Copy it from the page URL', which goes beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates the Job List DB in Notion with the correct schema, and it is a one-time setup. It distinguishes from sibling tools like auto_apply, log_to_notion, etc., which have different purposes.
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 explicitly says 'Run this before using log_to_notion' and mentions it skips if already set, providing clear guidance on when to use. However, it lacks explicit instructions on when not to use or alternatives.
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:

[![jobpilot-mcp MCP server](https://glama.ai/mcp/servers/TheCodeDaniel/jobpilot-mcp/badges/card.svg)](https://glama.ai/mcp/servers/TheCodeDaniel/jobpilot-mcp)

Score Badge

Copy to your README.md:

[![jobpilot-mcp MCP server](https://glama.ai/mcp/servers/TheCodeDaniel/jobpilot-mcp/badges/score.svg)](https://glama.ai/mcp/servers/TheCodeDaniel/jobpilot-mcp)

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/TheCodeDaniel/jobpilot-mcp'

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