Skip to main content
Glama
FreeApply

FreeApply

Official
by FreeApply
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
JavaScript
Local

Record what an employer did

freeapply_record_outcome
Idempotent

Records each employer's response to a job application—acknowledged, replied, assessment, interview, rejected, or offer—so you can track replies and update the job's outcome.

Instructions

Records what an employer did with an application: acknowledged, replied, assessment, interview, rejected or offer. Unlike freeapply_update_job, which records your side (applied, skipped, ...), it is about the employer's response. Use it for each employer email found during a reply check, between freeapply_reply_check start and finish, and when the user tells you about a call or corrects an outcome. Not for your own steps. Behavior: with an email (gmail_message_id) it stores the email and raises the job's outcome only if this email ranks higher than the current one (an interview outranks an acknowledgement); the same gmail_message_id again stores nothing new. Without an email it sets the outcome exactly, whatever its rank, and an empty outcome clears it. Parameters: outcome is required; "" clears it, without an email only. job_id, from the reply-check plan or freeapply_list_jobs, is required without an email; with an email it is optional, but then no outcome changes. The email fields fill the dashboard's Replies tab: gmail_thread_id, company, sender, subject, received_at (ISO 8601), summary (at most 20 words, no personal data beyond what is needed) and mail_action (starred, labeled:, starred+labeled: or none). Returns: with an email {recorded, kind, job_id, outcome}, where outcome is the job's outcome afterwards and both are null without job_id; without one {job_id, outcome}. Errors: an unknown job_id, no job_id and no email, or an empty outcome with an email.

Input Schema

NameRequiredDescriptionDefault
job_idNoThe job it is about.
senderNoWith an email: sender address.
companyNoWith an email: the employer that sent it.
outcomeYesWhat the employer did: acknowledged (automatic 'we received your application' email), replied (a person replied), assessment (test, assignment or screening questionnaire), interview (interview requested or scheduled), rejected (rejection), offer (offer), withdrawn (candidate withdrew); or "" to clear it.
subjectNoWith an email: subject line.
summaryNoWith an email: one sentence on what it says.
mail_actionNoWith an email: what you did with it in Gmail.
received_atNoWith an email: when it arrived (ISO 8601).
gmail_thread_idNoWith an email: Gmail thread id.
gmail_message_idNoThe employer email's Gmail message id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.2

TDQS

A4.9/5.0
Behavior5/5

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

Goes well past the annotations: it discloses the rank-based raise-only rule with an email, exact-set semantics without one, deduplication of a repeated gmail_message_id, the clearing behavior of an empty outcome, and enumerated error conditions. It is consistent with idempotentHint=true and non-destructive framing.

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 purpose, then behavior, parameters, returns, and errors in a predictable order with no filler sentences. It is dense and long, but nearly every clause carries conditional or semantic information an agent needs.

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?

For a 10-parameter mutation tool with no output schema, it supplies the return shapes for both branches and the error cases, so an agent can call it and interpret the result without inference. Nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, but the description adds conditional logic the schema cannot express: job_id is required without an email but optional (and outcome-inert) with one, and empty outcome is only valid without an email. It also supplies the mail_action value vocabulary and a 20-word/no-PII constraint on summary that the schema omits.

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+resource ('Records what an employer did with an application') and enumerates the exact outcome space. It explicitly contrasts with freeapply_update_job (employer's response vs. your own side), making it distinguishable from the closest sibling without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

States concrete triggers (each employer email found during a reply check, between freeapply_reply_check start and finish, when the user reports a call or corrects an outcome) and an explicit exclusion ('Not for your own steps'), pointing at the sibling that covers that case.

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

Deploy Server

Other Tools