Job Tracker MCP Server

by AshC2004

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action: application creation/status/list, follow-up creation/listing/completion, and pipeline summary. There is no overlap between the application and follow-up subdomains.
Naming Consistency5/5
All tool names follow a clear verb_noun pattern with snake_case (e.g., add_application, list_applications, mark_followup_done). The consistency makes the toolset predictable and easy to navigate.
Tool Count5/5
Seven tools is a well-scoped count for a job tracker. Each tool covers an essential operation, and the number feels neither excessive nor sparse for the domain.
Completeness4/5
The toolset covers the core lifecycle: adding applications, updating status, listing with filters, and follow-up management. It lacks a delete application or update application details, but these are minor gaps that can be worked around.
Average 3.5/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit 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 provided, and the description does not disclose any behavioral traits such as validation rules, duplicate handling, required field formats, or side effects. The description simply states the action without elaborating on what happens or under what conditions it may fail.
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, clear sentence with no redundancy or extra words. It is concise and well-structured, though it is under-specified for the complexity of the tool.
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 description does not provide enough context for a tool with six parameters and no annotations. It does not explain the expected format for date_applied, the allowed status values, or how this interacts with the tracker system. The output schema is present, but the description itself is incomplete.
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?
With schema description coverage at 0%, the description must compensate for parameter meaning, but it does not mention any of the six parameters. The agent is left to infer meaning solely from parameter names, which is insufficient for parameters like 'status' and 'date_applied' that may have specific expected formats.
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 ('Add') and resource ('job application'), clearly distinguishing this tool from the sibling 'add_followup' which adds follow-ups instead. The phrase 'to the tracker' provides additional context for the domain.
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 clearly implies the tool is for creating new job applications, but it does not explicitly state when to use this over alternatives like add_followup or when not to use it. Usage is inferred from the resource name rather than explicitly stated.
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 the core purpose and does not disclose behavioral traits such as whether the application must already exist, whether the reminder appears in get_pending_followups, side effects on application status, or timezone handling. For a scheduling tool, this is insufficient behavioral disclosure.
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 with no filler or redundant information. It efficiently states the tool's purpose, making it appropriately concise and front-loaded.
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?
While the tool has only three parameters, the description provides no context about prerequisites (e.g., application must exist), date format expectations, or how this relates to sibling tools like 'get_pending_followups' and 'mark_followup_done'. Though an output schema exists, its contents are not available, so the description carries the burden and falls short.
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%, meaning the description provides no information about parameters. The schema itself only gives names and types (e.g., application_id integer, follow_up_date string) without semantic context. The description does not mention that follow_up_date should be in a specific format, whether note is optional, or how application_id relates to existing applications.
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 ('Schedule') and resource ('follow-up reminder tied to an application'), making the tool's purpose immediately clear. It distinguishes itself from siblings like 'mark_followup_done' (completion vs. creation) and 'get_pending_followups' (listing vs. creation).
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 phrasing 'tied to an application' implies the tool requires an existing application and is meant for scheduling reminders, but it does not explicitly state when to use this tool over alternatives or when not to use it. No exclusions or alternative tool names are provided.
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 alone must convey behavioral traits. It indicates mutation ('Update') but does not disclose whether the operation is idempotent, whether it requires special permissions, what happens to old status values, or any side effects. This is a significant gap 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, concise sentence that front-loads the core action and resource. No filler or unnecessary information exists; it earns its place as a clear, brief statement.
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 a simple 2-parameter schema and an output schema, the description omits crucial context like allowed status values and usage scenarios. The tool is simple, but the lack of any parameter semantics or behavioral details leaves an under-specified picture, making it incomplete for reliable agent invocation.
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 0%, so the description must compensate for parameter clarification. It mentions 'pipeline status' which implies new_status is a status value, but it does not enumerate valid statuses or explain the format of new_status or application_id beyond their names. The agent is left guessing acceptable values.
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 uses specific verb 'Update' and clearly identifies the resource as 'pipeline status of an existing application.' This distinguishes it from sibling tools like add_application, list_applications, and add_followup, each of which has a different action and target.
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?
The description gives no explicit indication of when to use this tool versus alternatives. It does not mention use cases, exclusions, or refer to sibling tools. The context is implied but not directly stated, so an agent has no guidance beyond the basic action.
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 present, so the description must carry the burden. It only states the obvious action without disclosing side effects, idempotency, or behavior when the follow-up is already marked done. Minimal 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?
A single, front-loaded sentence that immediately states the tool's purpose. No unnecessary words or repetition.
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, but the description lacks behavioral details (e.g., side effects, error conditions) and does not explain the parameter. However, the output schema exists, so return values are covered elsewhere.
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 0% and the description does not explain followup_id. Although the parameter name is self-explanatory, the description adds no meaning beyond the schema's type definition.
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 (mark) and resource (follow-up reminder) with a specific outcome (completed). It is easily distinguished from sibling tools like add_followup (creation) and get_pending_followups (listing).
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?
Usage is implied (when a follow-up is completed, mark it done), but there is no explicit mention of when not to use it or alternatives. No exclusions or conditions are 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, the description must carry the full burden. It discloses key behavior: list ordering (newest first) and optional filtering by status. It does not mention any other behavioral traits such as pagination, limits, or side effects (though as a list operation, side effects are unlikely). The description provides basic transparency but no deeper detail beyond what the name implies.
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 front-loads the primary purpose, then adds two qualifiers (optional filter and ordering). Every word contributes meaning, with no redundancy or filler. It is appropriately sized for the tool's simplicity.
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 low complexity (one optional parameter, output schema provided), the description covers the core purpose, the filter behavior, and result ordering. The output schema likely documents the return shape, so the description need not repeat that. The only missing element is explicit usage guidance versus sibling tools, but the overall picture is quite complete for a listing read operation.
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 only parameter 'status' has no schema description, and the schema coverage is 0%. The description adds semantic meaning by stating that 'status' is an optional filter. However, it does not explain allowed values, the meaning of an empty string default, or the behavior when omitted. The description partially compensates for the schema gap but not completely.
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 with a specific verb and resource: 'List job applications'. It adds the optional status filter and the ordering 'newest first', which distinguishes it from sibling mutation tools like add_application and update_status. The purpose is unambiguous and self-contained.
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 this is the tool to use for viewing job applications, with optional status filtering. However, it does not explicitly mention when not to use it or how it relates to alternatives like pipeline_summary or get_pending_followups. There is no exclusionary guidance, so the usage context is clear but under-specified.
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 full burden. It uses 'List' which suggests a read-only operation, but it does not explicitly state that no state changes occur or address edge cases like timezone handling. The output schema likely documents return values, so missing that is acceptable.
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 that front-loads the verb and resource, then specifies the filtering criteria. No wasted words.
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 the core behavior and parameter meaning for a simple read operation. The presence of an output schema covers return value details. However, it lacks explicit usage guidance or edge-case handling, though these are less critical for a straightforward listing tool.
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 input schema has a single parameter as_of_date with no description in the schema. The tool description explains that it is the date for which follow-ups due on or before that date are included, adding semantic meaning to the 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 uses the verb 'List' with a specific resource 'follow-ups' and clearly specifies the filter (due on or before the given date and not done). This distinguishes it from sibling tools like list_applications and add_followup.
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 querying pending follow-ups, but it does not explicitly state when to use this tool over alternatives, nor does it mention exclusions. The context of sibling tools (e.g., mark_followup_done) makes the purpose clear, but explicit guidance is missing.
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 burden of behavioral disclosure. 'Return counts' clearly implies a read-only query with no side effects. While it does not detail edge cases or performance implications, the simple operation is sufficiently 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?
The description is a single, focused sentence with no wasted words. It conveys the essential action and resource immediately.
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 simple aggregation purpose, empty input schema, and presence of an output schema, the description fully conveys what the tool does. The output schema handles the return shape, so no additional detail is necessary.
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 description-level parameter semantics are not needed. The baseline for 0 parameters is 4, and the description correctly avoids inventing parameters.
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 verb 'Return' and the resource 'counts of applications grouped by pipeline status'. It distinguishes itself from siblings like list_applications (raw list) and add_application (create operation) by specifying an aggregate view.
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 phrase 'counts grouped by pipeline status' clearly implies a summary use case, and the sibling names provide context for when to use this instead of list_applications. However, it does not explicitly mention exclusions or alternative tools.
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:

[![job-tracker-mcp-server MCP server](https://glama.ai/mcp/servers/AshC2004/job-tracker-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/AshC2004/job-tracker-mcp-server)

Score Badge

Copy to your README.md:

[![job-tracker-mcp-server MCP server](https://glama.ai/mcp/servers/AshC2004/job-tracker-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/AshC2004/job-tracker-mcp-server)

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/AshC2004/job-tracker-mcp-server'

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