tracker-mcp

Overview Schema Source Related Servers Discussions Admin

Match e-mails to applications

match_emails

Read-only

Identifies which job application each email concerns and whether it is a confirmation, rejection, interview invitation, or offer, then suggests tracker rows and write actions to record it.

Instructions

Which application each e-mail is about and what it says: a confirmation, a rejection, an interview invitation or an offer. The company comes from the subject, the sender's name or the sender's own domain (not from applicant-tracking systems such as Ashby, Greenhouse, Lever or Workable). Each message gets the matching rows and the write tool that would record it, with the e-mail's date. Suggestions only: fetch the messages with your mail tool first, and make each change with its write tool after the user's yes.

Input Schema

Name	Required	Description	Default
`messages`	Yes	E-mails from the user's mailbox, each {from, subject, date, snippet}: the sender as in the From header, the date as ISO or RFC 2822, a few hundred characters of the body

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.5.1Oct 25, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds real value beyond that: it states the output is advisory, that each message is paired with the write tool that would record it, and that sender/company attribution comes from subject, sender name or domain rather than ATS vendors. It omits the 200-message cap and any failure behavior, keeping it below a 5.

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?

Content is front-loaded with the meaning of the output, then the attribution rule, then the workflow caveat. A couple of clauses run long (the ATS parenthetical, the final sentence), but every 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?

Output schema exists, yet the description still tells the agent what the rows and write-tool pairing mean, which is the non-obvious part. Combined with the single fully-documented parameter and clean annotations, nothing needed to call it correctly is missing.

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%, with the messages parameter fully documented ({from, subject, date, snippet}, ISO/RFC 2822 dates). The description restates that these are e-mails from the user's mailbox but adds no new syntax or constraints, so baseline 3 applies.

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?

Names a specific verb (match) and resource (e-mails to applications), then enumerates the output categories (confirmation, rejection, interview, offer). The agent can tell exactly what it gets back without opening the schema.

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?

Explicit procedural guidance: fetch messages with the mail tool first, apply changes with the write tool only after the user's yes, and treat results as suggestions. It doesn't name a sibling alternative (e.g., list_applications) for the non-email case, so it stops short of full when-not guidance.

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