AI agents keep your job search organized; you review and plan in a clean dashboard.
Agents write over a remote MCP server (streamable HTTP, OAuth 2.1) at https://app.jobctl.app/mcp
Humans read at jobctl.app: pipeline board, analytics, interview timeline, CV/cover attachments
Published in the official MCP Registry as io.github.DmytroRybka/jobctl and listed as a Glama connector (Healthy, tool quality A)
This repo ships the Claude Code plugin/skill, plus a thin stdio bridge (jobctl-mcp) for clients that prefer local stdio servers.
claude mcp add --transport http jobctl https://app.jobctl.app/mcp \
--header "Authorization: Bearer jc_..." # token: app.jobctl.app/settings
/plugin marketplace add DmytroRybka/jobctl-claude
/plugin install jobctl@jobctlThen just talk: "I applied to Bosch as Tech Lead, prio A, due friday" - Claude keeps the tracker current while you interview.
Related MCP server: job-pilot
Remote (recommended) - any client with streamable HTTP support connects to https://app.jobctl.app/mcp. OAuth 2.1 with dynamic client registration is supported; static bearer tokens (jc_...) work everywhere.
Local stdio server - this repo ships server.mjs, a standalone MCP server (stdio) exposing the same 10 tools, backed by the jobctl.app API:
git clone https://github.com/DmytroRybka/jobctl-claude && cd jobctl-claude
npm install
JOBCTL_TOKEN=jc_... node server.mjsor via Docker:
docker build -t jobctl-mcp . && docker run -i --rm -e JOBCTL_TOKEN=jc_... jobctl-mcpThe server starts and lists tools without a token (introspection); every tool call requires JOBCTL_TOKEN (create one at app.jobctl.app/settings).
Tool | What it does |
| Create an application from structured fields or a raw string ("Bosch, Tech Lead, prio A, due friday") with deterministic parsing and duplicate detection |
| Filter by status, priority, text query and saved views |
| Full detail: timeline, contacts, interviews, attachments |
| Status, priority, salary, next action and more |
| Append a note to the application timeline |
| Schedule or debrief interviews with attendees and links |
| Overdue and upcoming next actions |
| Agenda for today / tomorrow / this week |
| Attach a single replaceable company-analysis markdown (max 100 kB) |
| Attach CV or cover letter files (base64) |
Your data lives in your account only; full JSON export and GDPR account deletion are built in
The API is deterministic - no LLM calls server-side; your agent is the AI layer
Every change is an auditable event with an actor tag (agent / human / system)
Track a new job application. Pass either a single raw line - add_application({raw: "Bosch, Tech Lead, prio A, due friday, remote, via LinkedIn"}) - or structured fields (company and role required then). Returns the created application and possible-duplicate warnings; if duplicates are listed, tell the user instead of creating again.
| Name | Required | Description | Default |
|---|---|---|---|
| raw | No | Free-form line: "Company, Role, prio A|B|C, due <date>, remote|hybrid|onsite, via <source>, https://..., in <location>, applied <date>" | |
| url | No | Link to the job posting | |
| role | No | ||
| remote | No | ||
| source | No | LinkedIn, referral, recruiter, Easy Apply... | |
| status | No | ||
| company | No | ||
| location | No | ||
| priority | No | A = top priority | |
| applied_at | No | ISO date YYYY-MM-DD | |
| cv_variant | No | Which CV was sent: DE, EN, AI-focused... | |
| match_notes | No | Markdown match assessment: why the candidate fits this role - strengths vs requirements, gaps, level/salary advice, process notes. Save your vacancy analysis here so it is not lost; shown as an expandable section in the dashboard. | |
| next_action | No | e.g. "follow-up", "thank-you email" | |
| remote_note | No | e.g. "2 days office" | |
| salary_asked | No | What the candidate asked for - yearly gross EUR as a plain number, e.g. 110000 | |
| salary_range | No | Posting salary range upper bound - yearly gross EUR, plain number | |
| next_action_due | No | ISO date YYYY-MM-DD | |
| salary_range_min | No | Posting salary range lower bound - yearly gross EUR, plain number | |
| next_interview_at | No | ISO datetime, e.g. 2026-07-20T14:00:00+02:00 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return behavior: 'Returns the created application and possible-duplicate warnings'. Discloses duplicate detection and user instruction. Annotations have readOnlyHint=false and destructiveHint=false, which align with a create operation. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus an example. It is front-loaded with the core purpose and immediately provides usage clarity. Every sentence is informative with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 19 parameters and no output schema, the description covers the key behaviors (two input modes, duplicate warnings). It might lack guidance on parameter combinations, but it is sufficiently complete for an AI to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 74% schema coverage, the description adds value by providing an example for the raw parameter and clarifying that company and role are required in structured mode. It doesn't re-describe all parameters, but the schema already covers them adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Track a new job application.' It explains both usage modes (raw line or structured fields) and distinguishes from sibling tools like list_applications and update_application by being a create operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on when to use raw vs structured fields: 'Pass either a single raw line... or structured fields'. Also instructs on handling duplicates: 'if duplicates are listed, tell the user instead of creating again'. Missing explicit when-not-to-use, but covers common scenarios well.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Append a free-text note to an application timeline - recruiter call summaries, interview instructions, pasted messages. Multiline markdown is fine. Example: add_note({application_id: "...", text: "Recruiter: team of 5, on-call rotation, offer range 85-95k"}).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| application_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false (mutation) and destructiveHint=false (not destructive). The description adds 'append' which clarifies it is additive, but does not elaborate on side effects or permissions. With annotations covering safety profile, description provides adequate but minimal extra behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a code example. Front-loaded with purpose and usage. Every word adds value, no redundancy. Example is concise and instructive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, clear annotations), the description covers all needed aspects: purpose, usage context, parameter details, and an example. No gaps remain for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage (no property descriptions), so the description carries full burden. It explicitly mentions both parameters (application_id and text) and describes text as 'free-text note' and 'multiline markdown is fine'. The example shows expected values and format, adding substantial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Append a free-text note to an application timeline' with specific examples of note types (recruiter call summaries, interview instructions). This distinguishes it from sibling tools like add_application or log_interview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context on when to use the tool (recruiter call summaries, interview instructions, pasted messages) and includes a concrete example. It does not explicitly state when not to use it or list alternatives, but the provided context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Attach a markdown company analysis (research you produced) to an application. Single document per application - a new call REPLACES the previous one. Max 100000 bytes (~100 KB) of utf-8. The user reads it in the dashboard, e.g. before an interview. Example: attach_analysis({application_id: "...", markdown: "# Bosch\n\n## Culture..."}).
| Name | Required | Description | Default |
|---|---|---|---|
| markdown | Yes | The analysis as markdown | |
| application_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Disclosures destructive behavior (replaces previous), size limit (100KB), and user-facing purpose (dashboard). Complements annotations (destructiveHint=true) without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Multiple sentences each adding value (size limit, replacement behavior, usage context). Example is helpful but slightly extends length; overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully covers all key aspects for a two-parameter tool: purpose, replacement semantics, size constraints, and end-user consumption, needing no further clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has minimal description for 'markdown'; description adds context that it is 'company analysis (research you produced)' and provides a concrete example, compensating for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('Attach') + resource ('company analysis') + destination ('to an application'). Distinguishes from sibling 'attach_file' by specifying markdown analysis content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Single document per application - a new call REPLACES the previous one', providing clear usage context. Lacks explicit mention of when not to use, but context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Attach or replace a file on an application so the user sees it in the dashboard: a CV/resume (kind: 'cv') or a cover letter (kind: 'cover_letter'). Pass the file bytes as base64 in data_base64. One file per (application, kind) - a new call REPLACES the previous one. Max ~5 MB; pdf/doc/docx/txt/md (MIME is inferred from the filename if you omit it). Call this whenever you generate a tailored CV or cover letter for an application. Example: attach_file({application_id: "...", kind: "cv", filename: "CV_Cursor.pdf", data_base64: "JVBERi0..."}).
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| mime | No | Optional; inferred from the filename extension when omitted | |
| filename | Yes | ||
| data_base64 | Yes | Base64-encoded file bytes | |
| application_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true; the description confirms and expands: 'a new call REPLACES the previous one'. Adds details on max size (~5 MB), allowed formats (pdf/doc/docx/txt/md), and MIME inference. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph, front-loaded with action and purpose, followed by key details and a clear example. Every sentence adds value. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 params and no output schema, the description covers purpose, usage, behavior, constraints, and an example. Does not mention error conditions, but for a file attachment tool it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 40% (descriptions for mime and data_base64). Description adds value by stating file size limit, allowed formats, and replacement behavior per (application, kind). Kind enum is enriched with natural language definitions. Example provides context for all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Attach or replace a file on an application'. It specifies the resource (application), file types (CV or cover letter), and the effect. The tool is distinct from sibling tools like add_application or attach_analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States when to call: 'whenever you generate a tailored CV or cover letter'. Explains replacement semantics and file constraints. However, no explicit mention of when NOT to use or alternatives like attach_analysis. Good but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full detail of one application: all fields, contacts, recent timeline events, and whether a company analysis is attached (fetch it via the dashboard or attach_analysis to replace).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, which the description aligns with. The description adds behavioral context: returns all fields, contacts, timeline events, and an analysis flag. It also hints at related operations (fetch via dashboard, attach_analysis) but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that efficiently communicates the tool's purpose and key data inclusions. No wasted words; essential details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter, the description covers the return content adequately. It provides actionable context (e.g., analysis attachment hint). Missing error/edge cases but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (id, uuid) is implied by context ('one application') but not explicitly described. Since schema coverage is 0%, the description should add meaning, but it only indirectly indicates identification. It does not explain format or constraints beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves full detail of one application, specifying included data: fields, contacts, recent timeline events, and analysis attachment status. It distinguishes from sibling tools like list_applications (list vs single) and get_planned (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when detailed view of a single application is needed. It mentions alternatives for further actions (e.g., 'fetch it via the dashboard or attach_analysis to replace'), but does not explicitly state when not to use this tool or compare directly to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What is burning today: applications with next_action_due today or overdue. Call this when the user asks "what should I do today?" about their job search.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already provide readOnlyHint=true, so the safety profile is known. The description adds behavioral context by specifying it returns applications with due or overdue next_action_due. No additional details like authentication or rate limits, but sufficient for this simple read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The key information is front-loaded: what the tool returns and when to call it. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately specifies the output (applications with due/overdue next_action_due). It doesn't detail return format or pagination, but for a simple filter tool, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema description coverage is 100%. With 0 parameters, the description does not need to add parameter information, so baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb ('get') and resource ('due actions') and clearly states it retrieves applications with next_action_due today or overdue. It distinguishes from sibling tools by giving a concrete use case, e.g., not listing all applications or planned actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to call: when the user asks 'what should I do today?' about their job search. It provides clear context for usage, though it does not explicitly mention when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What is actually SCHEDULED: interviews with their time, attendees and meeting links, plus the actions falling due, for today, tomorrow, or the next seven days. Use this whenever the user asks what is planned, what the day or week looks like, or before proposing a time to anyone - get_due only knows action deadlines and is blind to booked interviews. Example: get_planned({range: "tomorrow"}).
| Name | Required | Description | Default |
|---|---|---|---|
| range | No | today (default), tomorrow, or week (today plus the next 6 days) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true; description adds context that it returns interviews with time, attendees, meeting links, and actions due, which is useful. No contradictions or missing behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus an example, front-loaded with key information, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately describes what is returned (interviews, actions due) and range options. It also distinguishes from get_due, making it contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with enum and description, but the description reinforces the parameter through natural language ('today, tomorrow, or the next seven days') and provides an example, adding clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows scheduled interviews and actions due for specific ranges, using specific verbs like 'shows' and 'is scheduled'. It distinguishes itself from sibling tool get_due by noting that get_due only knows action deadlines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use it: when user asks about plans, day/week looks, or before proposing a time. Also provides a contrast with get_due and gives an example usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List job applications. Filter by view (active = default working set, archive = rejected/withdrawn/no-response), status list, priority, or free-text search in company/role. Example: list_applications({view: "active"}), list_applications({q: "bosch"}).
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Search in company/role | |
| view | No | ||
| limit | No | ||
| status | No | Comma-separated: started_apply, waiting_referral, applied, waiting, interview, offer, accepted, rejected, no_response, on_hold, withdrawn, archived | |
| priority | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
ReadOnlyHint annotation already covers safety. Description adds filter defaults but not other behaviors like pagination or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus two examples, no wasted words. Front-loaded with core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers filtering well but omits pagination behavior despite a limit parameter. No output schema, so return format is assumed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 40% schema coverage, description explains view enum, free-text search, and provides examples, compensating for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List job applications' and enumerates filters. Lacks explicit sibling differentiation but is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides filter context and examples, but does not specify when to use this tool over siblings like get_due or get_planned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Log an interview for an application (max 10 per application): when it takes place, its status (planned or done), who attends (each with an optional profile link), related links (prep materials the company sent, meeting URL), and a short recap of what was discussed. Also keeps the application's next-interview date in sync. Example: log_interview({application_id: "...", scheduled_at: "2026-07-20T14:00:00+02:00", status: "planned", attendees: [{name: "Anna Weber (HR)", url: "https://linkedin.com/in/annaweber"}], links: [{label: "Prep materials", url: "https://company.com/interview-prep"}], recap: "System design round"}).
| Name | Required | Description | Default |
|---|---|---|---|
| links | No | Related links: prep materials, meeting URL, docs | |
| recap | No | Short recap of what was discussed | |
| status | No | planned (default) or done | |
| attendees | No | Who attends, each with an optional profile link | |
| scheduled_at | Yes | ISO datetime with offset, e.g. 2026-07-20T14:00:00+02:00 | |
| application_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-readonly and non-destructive. Description adds side-effect context: 'keeps the application's next-interview date in sync.' No contradiction. Lacks details on authentication or rate limits but sufficient for a simple creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two focused sentences plus example. Front-loaded with action and constraint. Every sentence adds value: purpose, fields, side effect, example. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers inputs, behavior, and side effect. No output schema, but description adequate. Could mention max limit enforcement or error cases, but overall complete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 83% description coverage. Description adds meaning by enumerating fields (scheduled_at, status, attendees, links, recap) and providing an example. Clarifies 'status' enum and 'profile link' optionality, supplementing schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Log' and resource 'interview for an application', includes max limit (10 per application), lists key fields, and provides a concrete example. Clearly distinguishes from siblings like 'add_note' or 'attach_analysis'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States clear purpose and constraint ('max 10 per application'). While no explicit 'when not to use' or alternatives, the context signals show distinct sibling tools, and the description implies when to invoke (recording an interview). Could be improved with 'use this instead of...' but still clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update fields of an application (get the id from list_applications). Status changes are logged to the timeline automatically. Example: update_application({id: "...", status: "interview", next_action: "prepare system design", next_action_due: "2026-07-20"}).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| url | No | Link to the job posting | |
| role | No | ||
| remote | No | ||
| source | No | LinkedIn, referral, recruiter, Easy Apply... | |
| status | No | ||
| company | No | ||
| location | No | ||
| priority | No | A = top priority | |
| applied_at | No | ISO date YYYY-MM-DD | |
| cv_variant | No | Which CV was sent: DE, EN, AI-focused... | |
| match_notes | No | Markdown match assessment: why the candidate fits this role - strengths vs requirements, gaps, level/salary advice, process notes. Save your vacancy analysis here so it is not lost; shown as an expandable section in the dashboard. | |
| next_action | No | e.g. "follow-up", "thank-you email" | |
| remote_note | No | e.g. "2 days office" | |
| salary_asked | No | What the candidate asked for - yearly gross EUR as a plain number, e.g. 110000 | |
| salary_range | No | Posting salary range upper bound - yearly gross EUR, plain number | |
| next_action_due | No | ISO date YYYY-MM-DD | |
| salary_range_min | No | Posting salary range lower bound - yearly gross EUR, plain number | |
| next_interview_at | No | ISO datetime, e.g. 2026-07-20T14:00:00+02:00 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, so the description adds value by stating that status changes are automatically logged to the timeline. This is a behavioral trait beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an inline example. It is front-loaded with the core action, concise, and every part adds value without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 19 parameters and moderate schema coverage, the description is adequate but minimal. It lacks explanation of partial updates, error conditions, or return values. The example provides some context but does not fully cover the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 68%, with many parameters already described in the schema. The description provides a helpful example but does not add new semantic information for individual parameters beyond what the schema already offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Update fields of an application' with explicit verb and resource. It distinguishes from siblings like add_application, list_applications, and get_application via the context of modifying an existing application.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides a direct hint: 'get the id from list_applications' indicating prerequisite. It also notes automatic timeline logging for status changes. However, it does not explicitly specify when not to use this tool or mention alternatives for related actions like adding notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.1add_applicationadd_noteattach_analysisattach_fileget_applicationget_dueget_plannedlist_applicationslog_interviewupdate_applicationEach tool has a clearly distinct purpose: get_due and get_planned handle different timeframes, add_application creates, list_applications filters, get_application provides detail, update_application modifies, add_note appends notes, log_interview manages interviews, attach_analysis and attach_file handle documents. No overlaps.
All tool names follow the verb_noun pattern in snake_case (e.g., add_application, get_due, attach_file), maintaining a consistent and predictable structure.
With 10 tools, the set is well-scoped for a job application tracker, covering creation, listing, retrieval, updates, notes, interviews, files, and analysis without being overwhelming.
The tool set covers core CRUD (add, list, get, update) and adds notes, interviews, files, and analysis. Missing delete capabilities for applications, notes, or interviews, but these are minor gaps given the focus on tracking.
Job application tracker for developers - AI agents write over MCP, you review in a dashboard.
AI job search MCP — fact-checked jobs, application tracker, alerts. ChatGPT, Claude, Cursor.
Job platform for AI agents. Track tech jobs from companies that match your stack.
Work management where AI agents are first-class members: tasks, projects, memory over hosted MCP
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/DmytroRybka/jobctl-claude'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
