job-application-tracker-mcp

List applications

list_applications

Read-only

List job and internship applications with optional status, company, text, and deadline filters, then sort results and view application IDs plus stage counts.

Instructions

List applications with optional status and company filters, an optional text query and an optional deadline range. Inputs: optional status to filter by stage, an optional company substring to match (case insensitive), an optional query that searches the role, notes and source text (case insensitive), for example referral or LinkedIn, and optional deadline_after and deadline_before as YYYY-MM-DD. Both dates are included, and applications without a deadline are left out when you pass either one. An optional sort orders the list by deadline (nearest first, applications without a deadline last), company (A to Z) or id (the default). Returns all matching applications as a structured list with their ids, so you can see application ids without exporting a full report, plus summary_counts with how many of them are in each stage. Example prompt: "Show my applications by nearest deadline."

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_applications"
  }
}

Input Schema

Name	Required	Description
`sort`	No	Order the list by deadline (nearest first, no deadline last), company (A to Z) or id. Defaults to id.
`query`	No	Only list applications whose role, notes or source contains this text (case insensitive).
`status`	No	Only list applications in this stage.
`company`	No	Only list applications whose company name contains this text (case insensitive).
`deadline_after`	No	Only list applications with a deadline on or after this YYYY-MM-DD date.
`deadline_before`	No	Only list applications with a deadline on or before this YYYY-MM-DD date.

Output Schema

Name	Required	Description
`count`	Yes	How many applications match.
`applications`	Yes	The matching applications.
`summary_counts`	Yes	How many of the matching applications are in each stage.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.1Nov 3, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare a safe read-only, closed-world operation, and the description adds real behavior: applications without a deadline are dropped whenever either date bound is supplied, and null-deadline rows sort last. It does not mention result-size limits or pagination, which would matter for very large lists.

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?

Front-loads the summary, then enumerates inputs in the schema's order, then returns. It is somewhat long and repeats enum-like details already in the schema, and the closing example prompt is mild padding, but every substantive sentence carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite six optional parameters, an output schema, and non-obvious null-deadline semantics, the description covers filters, inclusion rules, sort behavior, and the shape of the return (ids plus summary_counts). An agent has everything needed to call it correctly without opening the schema.

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%, so baseline is 3; the description still earns credit by stating that the deadline bounds are inclusive and that filtering on them excludes undated applications, a semantic the schema does not spell out. Sort ordering ties (nearest first, no-deadline last, A-to-Z) is also restated usefully.

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?

Opens with a specific verb and resource plus the exact filter axes (status, company, text query, deadline range, sort). It is easy to distinguish from the mutating siblings (add_application, update_application, delete_application) and from export_report, which it explicitly positions against.

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?

Gives clear context ('see application ids without exporting a full report') and an example prompt that selects it. It lacks an explicit exclusion, e.g. when to prefer list_upcoming for deadline-focused views, which is the nearest overlapping sibling.

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

Deploy Server