What can you do with this server?

This server lets you manage job applications locally via MCP: add, delete, search, update, annotate, and analyze job application records stored in a local JSON file. * Add applications with company, job title, application date, and application link. * Search applications by company, job title, or status (Applied, Interview, Accepted, Rejected). * Delete applications using company name and job title. * Update application status to Applied, Interview, Accepted, or Rejected. * Update application details, including company, job title, date, and link. * Add notes to existing job applications. * List all saved job applications. * Get application statistics grouped by status. * Mark applications as favorites. * Detect duplicate applications by company name and job title. * The README also mentions retrieving full application details and searching by date range, plus a web UI for browsing applications.

How do I use NextFlows Academy MCP Starter?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@NextFlows Academy MCP Starter greet me as Alex" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

NextFlows Academy MCP Starter

by RoaM04

Overview Schema Related Servers Score Discussions

Local

Job Application Tracker MCP

A local Model Context Protocol (MCP) server for managing job applications. The server allows an AI assistant to add, delete, search, update, and manage job application data stored in a local JSON file.

The project works offline and does not require paid APIs or authentication.

This project was built as part of the NextFlows AI Academy.

Requirements

Before running the project, make sure you have:

Node.js 20 or later
npm
Git
VS Code or another code editor
MCP Inspector for testing the server

Check your Node.js and npm versions:

node -v
npm -v

Related MCP server: Hello World MCP Server

Install

Clone the repository:

git clone https://github.com/RoaM04/Job-Application-Tracker-Project.git

Move into the project folder:

cd Job-Application-Tracker-Project

Install the dependencies:

npm install

Run

Start the MCP server with:

npm run dev

The server runs using the stdio transport and waits for MCP requests.

You should see:

Job Application Tracker MCP server running on stdio

Keep the terminal running while using MCP Inspector.

Web Interface

A small web UI is also included for browsing job applications outside of an AI assistant.

Serve the static frontend (folder: public/):

npx serve public -p 3000

Start the backend web server:

node web/server.js

Once both are running, open http://localhost:3000 in your browser.

Note: run each command in its own terminal tab, and keep both running at the same time. Update the port number above if 3000 is already in use on your machine.

MCP Inspector

To test the server with MCP Inspector, run:

npm run inspect

Open the Inspector interface, connect to the server, and select Tools.

Choose one of the available tools and provide the required input.

The project stores its data in:

data/job-applications.json

The examples/ directory contains example JSON inputs that can be reused when testing tools.

Tools

Tool	Description
`add_job_application`	Adds a new job application to the local JSON data file.
`delete_job_application`	Deletes an existing job application after confirmation.
`update_application_status`	Updates the status of an existing job application.
`search_job_applications`	Searches job applications using the available search criteria.
`add_job_application_note`	Adds a note to an existing job application.
`remove_job_application_note`	Removes a note from an existing job application.
`list_job_applications`	Lists stored job applications.
`get_application_statistics`	Returns statistics about the stored job applications.
`update_job_application_details`	Updates details of an existing job application.
`get_job_application_details`	Retrieves full details of job applications by company, job title, or both.
`search_applications_by_date_range`	Searches applications within a specified date range.

All application data is stored locally in:

data/job-applications.json

No external API or authentication is required.

Example Prompts

These are examples of requests that can be used with an AI assistant connected to the MCP server:

Add a job application for Google for a Software Engineer position.

Delete my Google Software Engineer application.

Update the status of my Google Software Engineer application to Interview.

Show me my job applications.

Search for job applications at Google.

Add a note to my Google Software Engineer application.

Show me statistics about my job applications.

The exact input fields required by each tool can also be checked in MCP Inspector.

Connect to Claude Desktop

Inspector is great for development, but for Demo Day (or everyday use) you can connect this server directly to Claude Desktop so Claude can call the tools itself. This project uses a local stdio server, so it's added through Claude Desktop's config file — not through Claude.ai "Connectors" in the browser, which are for remote/HTTP servers.

1. Prerequisites

Claude Desktop installed and updated: claude.ai/download (macOS or Windows).
Node 20+ on your PATH — check with node -v and npx -v.
The server already runs in Inspector via npx tsx src/index.ts (or npm run dev) from the repo root.
The server logs only to stderr (console.error), never console.log to stdout, since stdio transport owns stdout.

2. Open Claude's MCP config

In Claude Desktop: menu bar Claude → Settings… → Developer → Edit Config.

This opens (or creates):

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

If other MCP servers are already listed there, add this one alongside them — don't remove existing entries.

3. Add this server

Replace the cwd path below with the absolute path to your local clone of this repo. cwd must be absolute so ./data fixtures resolve correctly (Claude does not start inside this folder).

macOS:

{
  "mcpServers": {
    "Job-Application-Tracker-Project": {
      "command": "npx",
      "args": ["-y", "tsx", "src/index.ts"],
      "cwd": "/Users/YOUR_MAC_USERNAME/path/to/Job-Application-Tracker-Project"
    }
  }
}

Windows: use npx.cmd (plain npx often fails), and double any backslashes in the JSON:

{
  "mcpServers": {
    "Job-Application-Tracker-Project": {
      "command": "npx.cmd",
      "args": ["-y", "tsx", "src/index.ts"],
      "cwd": "C:\\Users\\YOUR_WINDOWS_USERNAME\\path\\to\\Job-Application-Tracker-Project"
    }
  }
}

If npx / npx.cmd shows up as "not found," put the full path from which npx (macOS) or where npx (Windows) in command instead.

Make sure the file is valid JSON (no trailing commas, no comments), then save it.

4. Fully restart Claude Desktop

Quit the app completely — macOS: Claude menu → Quit Claude, not just closing the window — then reopen it. The config is only read at startup.

5. Confirm the tools loaded

In a new chat, open the tools/connectors panel next to the message box (Manage connectors, or the hammer/tools icon). You should see Job-Application-Tracker-Project and its tools listed.

Try one of the Example Prompts above and approve the tool call when Claude asks. If Claude picks the wrong tool, tighten that tool's description in the code and restart Claude Desktop.

6. If the server doesn't appear — debug in this order

Confirm cwd is an absolute, existing folder (the repo root, not src/).
From that same folder, manually run npx -y tsx src/index.ts. It should sit waiting on stdio with no crash — stop it with Ctrl+C.
Check Claude's MCP logs:
- macOS: ~/Library/Logs/Claude/mcp.log and mcp-server-Job-Application-Tracker-Project.log
- Windows: %APPDATA%\Claude\logs\
PATH issues: Claude Desktop does not load your shell profile, so use a full path to npx/node if needed.
Still stuck: copy the exact error from the log and use MCP Inspector as a fallback for testing/demoing.

Troubleshooting

1. `npm install` fails

Make sure Node.js 20 or later is installed:

node -v

If Node.js is missing or the version is too old, install a supported version and run:

npm install

again.

2. MCP Inspector cannot connect to the server

Make sure you are running the command from the project root:

npm run inspect

Also make sure there are no TypeScript or dependency errors in the terminal.

If the server is already running separately with npm run dev, stop it before starting Inspector if both commands try to use the same server process.

3. A tool cannot find or update an application

Check that:

data/job-applications.json

exists and contains valid JSON data.

For tests, restore the fixture data before trying another operation. Also make sure the company name and job title match an existing application.

Acknowledgments

Built as part of the NextFlows AI Academy program.

License

MIT License.

Available Tools

10 tools

add_job_applicationB

Add a new job application to the Job Application Tracker.

ParametersJSON Schema

Name	Required	Description
`company`	Yes	Name of the company offering the job
`jobTitle`	Yes	Title of the job position
`applicationDate`	Yes	Date when the application was submitted (YYYY-MM-DD)
`applicationLink`	Yes	Enter a complete link starting with https:// or http:// (e.g., https://company.com/job)

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden but only states the action without disclosing side effects, return value, idempotency, or error behavior. For a create tool, this is insufficient.

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, but its brevity leaves out useful context.

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?

Considering the 4 required parameters, lack of annotations, and presence of sibling tools for duplicates, the description is too sparse to fully inform the agent about tool behavior and constraints.

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 provides descriptions for all 4 parameters (100% coverage), so the description adds no additional semantic information beyond what is already 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 verb 'Add' and the resource 'job application' with a specific target 'Job Application Tracker', which distinguishes it from sibling tools like list, search, and delete.

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?

No explicit guidance on when to use this tool versus alternatives (e.g., checking for duplicates via detect_duplicate_applications before adding), nor any prerequisites or context cues.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

add_job_application_noteAdd Job Application NoteB

Add a note or comment to an existing job application.

ParametersJSON Schema

Name	Required	Description
`note`	Yes	The note or comment to add to the job application
`company`	Yes	Full company name of the job application
`jobTitle`	Yes	Full job title of the application

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the burden. It states only that a note is added, but does not disclose whether notes are appended or overwritten, behavioral limits (e.g., character count only in schema), or side effects.

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, clear sentence with no wasted words. Front-loaded and efficient.

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 mutation tool with 3 required parameters and no output schema, the description is too thin. It does not explain what happens if the application does not exist, any return value, or other behavioral context.

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 each parameter is already described. The description adds no additional meaning beyond what the schema provides, such as how company and jobTitle uniquely identify the application.

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 adds a note or comment to an existing job application, using a specific verb and resource. It distinguishes from siblings like 'add_job_application' which creates a new application.

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, prerequisites (e.g., application must exist), or when not to use it. No mention of alternatives like updating the application.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_job_applicationDelete Job ApplicationB

Delete an existing job application using its identifying information.

ParametersJSON Schema

Name	Required	Description	Default
`company`	Yes	Full name of the company for the application to delete
`jobTitle`	Yes	Full job title of the application to delete

TDQS

B3.3/5.0

Behavior2/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 only states the action 'delete' without disclosing whether deletion is irreversible, what side effects occur, or if specific permissions are required. This is minimal transparency for a destructive operation.

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 is concise and to the point. Every word earns its place, with no redundancy or filler.

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 deletion tool with full schema coverage and no output schema, the description is minimally adequate. However, it lacks any mention of irreversibility or return value, which would enhance 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% with clear descriptions for both parameters (company and jobTitle). The description adds no further meaning beyond what is already in the schema, so baseline 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 verb 'delete' and the resource 'job application', which is specific and distinguishes it from sibling tools that add, update, or search applications.

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 provides no guidance on when to use this tool versus alternatives, such as when a job application should be deleted versus its status updated. No context on prerequisites or consequences is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

detect_duplicate_applicationsDetect Duplicate ApplicationsA

Checks whether a job application with the same company name and job title already exists.

ParametersJSON Schema

Name	Required	Description	Default
`company`	Yes	Company name of the job application
`jobTitle`	Yes	Job title to check for duplicate applications

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the burden of behavioral disclosure. It states it checks for duplicates but does not mention what the tool returns (e.g., boolean, list) or if there are any side effects.

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 with no wasted words. It efficiently communicates the tool's core function.

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 simple tool and high schema coverage, the description is adequate but lacks explanation of the return value or behavior when no duplicate exists. Without an output schema, the description should clarify what the tool outputs.

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% with parameter descriptions already provided. The description adds the context that parameters are used together to detect duplicates, but this is essentially restating the tool's purpose, adding little new meaning beyond 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 checks for duplicate applications based on company and job title, which is a specific verb+resource combination. It distinguishes from siblings like list_job_applications or add_job_application by focusing on duplicate detection.

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 avoiding duplicates before adding, but it does not explicitly state when to use it or when not to, nor does it mention alternatives like search_job_applications.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_application_statisticsGet Application StatisticsA

Generate a summary of job applications grouped by application status.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full burden. It indicates the tool returns aggregated data grouped by status, which is a behavioral trait. However, it does not disclose aspects like whether the summary is real-time, cached, or requires any permissions.

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 that efficiently conveys the purpose. It is front-loaded and contains no filler, though it could be slightly more structured by hinting at the output format.

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 no parameters and no output schema, the description is fairly complete for the tool's simplicity. However, it lacks details about the summary's granularity (e.g., all statuses or only certain ones) and whether it's a live query or snapshot, which would help an agent decide.

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?

There are zero parameters, and schema description coverage is 100%. The description adds value by explaining what the tool does, meaning the schema alone is insufficient. Baseline score of 4 is appropriate for no parameters.

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 generates a summary grouped by application status. It is specific about the verb and resource, and context from sibling tools helps distinguish it from listing or searching individual applications.

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?

No explicit guidance on when to use this tool versus alternatives like list_job_applications or search_job_applications. The implied use is for aggregated statistics, but without stating exclusions or conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_job_applicationsList Job ApplicationsB

List all saved job applications.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations, so description must disclose behavior. It indicates a read operation listing all saved applications, but does not mention ordering, pagination, or return format. 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?

Single sentence with no filler. Extremely concise and front-loaded.

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 no output schema and simple function, the description covers the basic purpose. However, missing details about scope (e.g., current user's applications) or result ordering make it slightly incomplete.

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?

No parameters (0 params), so baseline 4 is appropriate. The description does not add parameter semantics, but none are needed.

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?

Description clearly states verb 'List' and resource 'all saved job applications', but does not differentiate from sibling 'search_job_applications' which might imply filtering. Still, for a simple list tool, the purpose is clear.

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 vs alternatives like search_job_applications. The description provides no context for choosing this tool over others.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mark_application_as_favoriteMark Application as FavoriteC

Marks a specific job application as favorite using the company name and job title.

ParametersJSON Schema

Name	Required	Description	Default
`company`	Yes	Company name of the job application
`jobTitle`	Yes	Job title of the application to mark as favorite

TDQS

C2.8/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden for behavioral disclosure. It does not state if the operation is idempotent, whether it requires existing applications, or any side effects. For a mutation tool, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, which is efficient but lacks important context. It is not overly verbose but could be improved with more detail without sacrificing 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?

Given the lack of annotations and output schema, the description is incomplete. It omits behavioral details like idempotency, existence requirements, and return values, which are critical for an agent to use this tool 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 coverage is 100% with clear parameter descriptions. The tool description merely restates the parameters ('using the company name and job title'), adding no additional meaning beyond the schema. Baseline 3 is appropriate.

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 marks a job application as favorite, using specific verb and resource. It distinguishes from sibling tools which handle listing, adding, searching, deleting, etc. However, it does not specify whether it toggles or sets favorite status, leaving slight ambiguity.

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, such as prerequisites (e.g., application must exist) or whether it should be used before checking if already favorited. The description lacks any contextual usage advice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_job_applicationsSearch Job ApplicationsB

Search for job applications by company name, job title, or application status.

ParametersJSON Schema

Name	Required	Description
`status`	No	Filter applications by application status.
`company`	No	Filter applications by company name.
`jobTitle`	No	Filter applications by job title.

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must disclose behaviors. It only mentions search functionality but does not state that it is read-only, idempotent, or any side effects. Missing details about sorting, pagination, or potential performance impact.

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?

Single sentence, front-loaded with the verb 'search' and resource 'job applications'. No redundant or verbose content.

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 no output schema, the description should mention what is returned (e.g., list of applications). It also lacks info on pagination or sorting. While simple tool, it leaves open questions about response format.

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 100% with individual parameter descriptions. The tool description merely lists the parameter names without adding semantic value beyond the schema. For high coverage, baseline is 3 but description adds minimal extra meaning.

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 for job applications by company name, job title, or application status. It distinguishes from sibling 'list_job_applications' which likely returns all applications without filters.

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 explicit guidance on when to use this tool versus alternatives like 'list_job_applications'. While it's implied to use search when filtering, the description does not mention when not to use it or provide alternative tool names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_application_statusUpdate Application StatusB

Update the status of an existing job application using the company name and job title.

ParametersJSON Schema

Name	Required	Description
`status`	Yes	New status of the job application
`company`	Yes	Full name of the company for the application to update
`jobTitle`	Yes	Full job title of the application to update

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, description carries full burden but only states 'update status'. It fails to describe expected behavior for missing applications, invalid status transitions, or side effects. 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?

Single sentence with no extraneous content. Front-loaded verb and resource. Every word earns its place.

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 simple nature of the tool (3 required params, no output schema), the description is minimally adequate but omits crucial context like error handling or uniqueness criteria. Could be more 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% with descriptions for each parameter. Description adds no new meaning beyond confirming parameters are used for identification. Baseline score of 3 is appropriate.

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 (update) and resource (status of job application), specifying identifying fields (company name and job title). It distinguishes from sibling 'update_job_application_details' by focusing on status, though not explicitly.

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 siblings like update_job_application_details or when not to use it. Context signals show sibling names but description itself provides no usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_job_application_detailsUpdate Job Application DetailsB

Update the company, job title, application date, or application link of an existing job application.

ParametersJSON Schema

Name	Required	Description
`company`	Yes	Current company name of the job application
`jobTitle`	Yes	Current job title of the application
`newCompany`	No	New company name
`newJobTitle`	No	New job title
`newApplicationDate`	No	New application date in YYYY-MM-DD format
`newApplicationLink`	No	New job application link

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description must disclose behavioral traits. It only states 'update' but does not mention prerequisites (e.g., application must exist), potential side effects, or authentication needs. This 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?

A single sentence of 17 words, front-loaded with the verb and resource. Every word contributes meaning, with no unnecessary repetition or filler.

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?

No output schema and no annotations. The description lacks details on whether updates are partial or atomic, how identifiers are used, and what return value to expect. For a 6-parameter mutation tool, this is incomplete.

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 lists fields that can be updated, but the schema already provides clear descriptions for each parameter (e.g., 'New company name'). The description adds minimal meaning beyond what the schema 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 clearly states the verb 'update' and the resource 'existing job application,' and lists specific fields (company, job title, application date, link). It distinguishes from sibling tools like update_application_status, which focuses on status updates.

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?

No explicit when or when-not guidance is provided. The description implies use for updating the listed fields, but does not mention alternatives like update_application_status for status changes. Some direction would help an agent choose correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

10 tool updatesv0.1.0Jul 30, 2026
- First observedadd_job_application
- First observedadd_job_application_note
- First observeddelete_job_application
- First observeddetect_duplicate_applications
- First observedget_application_statistics
- First observedlist_job_applications
- First observedmark_application_as_favorite
- First observedsearch_job_applications
- First observedupdate_application_status
- First observedupdate_job_application_details

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation5/5

Each tool targets a distinct action on job applications, so there is no ambiguity. For example, update_application_status and update_job_application_details clearly differ in what they modify.

Naming Consistency4/5

All tools use snake_case verb_noun patterns, but there is inconsistency in singular vs. plural usage (e.g., list_job_applications vs. add_job_application) and some drop 'job_' (update_application_status vs. update_job_application_details).

Tool Count5/5

10 tools is a reasonable number for a job application tracker, covering core operations without being excessive.

Completeness3/5

Missing a 'get single application' tool and full CRUD for notes (only add_note, no delete or update note). This creates potential dead-ends for agent workflows.

Maintenance

ActivityActive

ResponsivenessWithin a week

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2
test-mcp B
dev.riskprofiler
An MCP server that provides a hello tool
11
staging-mcpOAuth
dev.riskprofiler
An MCP server that provides a hello tool
1
strata
ai.klavis
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Agent Orchestration Autonomous Agents Developer Tools
25,748

Related MCP Servers

Hello World MCP Server
Developer Tools
Auxin-io
-
license
C
quality
Not graded
maintenance
A simple boilerplate MCP server that provides a basic greeting tool for demonstration purposes. Serves as a starting template for developers to quickly create and deploy custom MCP servers.
Updated a year ago (2025-09-29 02:12 UTC)
1
16
-
Hello World MCP Server
Developer Tools
Auxin-io
A
license
C
quality
D
maintenance
A simple MCP server that provides a basic greeting tool for saying hello with customizable names. Serves as a boilerplate template for developers to quickly create and deploy new MCP servers.
Updated a year ago (2025-10-03 10:56 UTC)
1
16
MIT
Hello MCP Server
Developer Tools Cloud Platforms
mfang0126
A
license
A
quality
D
maintenance
A simple MCP server that provides a basic greeting tool and serves as a starter template for AWS Lambda deployment. Demonstrates how to build and deploy MCP servers with both local development and cloud deployment capabilities.
Updated a year ago (2025-10-20 02:55 UTC)
1
17
MIT
Basic MCP Server
Developer Tools
cyberimaginationsi-gif
A
license
Not graded
quality
D
maintenance
A minimal template MCP server demonstrating basic tools, resources, and prompts functionality. Includes example implementations like a hello tool, history resource, and greet prompt for learning MCP development.
Updated 9 months ago (2025-12-12 06:44 UTC)
2
ISC

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/RoaM04/Job-Application-Tracker-Project'

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

Job Application Tracker MCP

Requirements

Install

Run

Web Interface

MCP Inspector

Tools

Example Prompts

Connect to Claude Desktop

1. Prerequisites

2. Open Claude's MCP config

3. Add this server

4. Fully restart Claude Desktop

5. Confirm the tools loaded

6. If the server doesn't appear — debug in this order

Troubleshooting

1. npm install fails

2. MCP Inspector cannot connect to the server

3. A tool cannot find or update an application

Acknowledgments

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `npm install` fails