GetMattered

Record a Follow-up

getmattered_record_follow_up

Records follow-ups you sent yourself via email or LinkedIn so application follow-up counts and next due dates stay accurate. Use when you sent a message outside GetMattered; nothing is sent or spent.

Instructions

Record a follow-up the user sent themselves, for example on LinkedIn or from their own mail app, so the application's follow-up count and next due date stay right. Pass application_id, body (the text they sent, 20 to 4,000 characters), and optionally channel (email, linkedin or other; email by default), recipient and subject. Nothing is sent from GetMattered and nothing is spent. A recorded follow-up cannot be removed with these tools, so record only what the user says they sent. Do not use it to send a follow-up; use getmattered_send_follow_up. Next: getmattered_get_inbox for the employer's answer.

Input Schema

Name	Required	Description
`body`	Yes	The text the user sent, 20 to 4,000 characters.
`channel`	No	Where the user sent it: email, linkedin or other. Defaults to email.
`subject`	No	The subject line, if the message had one.
`recipient`	No	Who it went to: an email address or a LinkedIn handle.
`application_id`	Yes	The application, from getmattered_list_due_follow_ups or getmattered_get_applications.

Output Schema

Name	Required	Description
`draft`	Yes	From getmattered_draft_follow_up: the drafted message. Nothing was sent.
`action`	Yes	The operation that ran: list, history, draft, send or record_sent.
`history`	Yes	From getmattered_list_sent_follow_ups: follow-ups already sent, newest first.
`recorded`	Yes	From getmattered_send_follow_up or getmattered_record_follow_up: the follow-up count after it was recorded.
`followUps`	Yes	From getmattered_list_due_follow_ups: applications whose follow-up is due, most urgent first.
`nextCursor`	Yes	From getmattered_list_sent_follow_ups: pass as cursor for the next page. Null on the last page.
`notConfirmed`	Yes	True when the user declined the confirmation and nothing was sent.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.10.2Oct 25, 2026

TDQS

A4.6/5.0

Behavior5/5

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

The annotations only show readOnlyHint=false, destructiveHint=false, and idempotentHint=false, without saying what the write does. The description adds real behavioral facts: nothing is sent or spent (openWorldHint=false is confirmed in words), and a recorded follow-up cannot be removed with these tools. This gives the agent the irreversibility profile it needs before writing.

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?

Purpose and side-effect disclaimers come first, the alternative second, and the next step last, so the order fits what an agent needs. It is a bit dense, and the parameter walkthrough duplicates schema content that could be cut.

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?

With annotations and an output schema present, the description supplies the remaining decision-critical info: negative side effects, irreversibility, the sibling alternative, and a next step. 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 coverage is 100%, so every parameter already has a description and enum. The description repeats body length, channel default, and the other fields without adding syntax or format beyond the schema. Baseline 3 applies since the schema already does the work.

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?

States a specific verb+resource ('Record a follow-up the user sent themselves') plus the mechanism (LinkedIn, own mail app) and the effect (follow-up count and next due date). This clearly separates it from getmattered_draft_follow_up and getmattered_send_follow_up, which appear in siblings.

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?

Explicit exclusion: 'Do not use it to send a follow-up; use getmattered_send_follow_up.' It also states the precondition ('record only what the user says they sent') and a next step (getmattered_get_inbox). The when/when-not pair is fully spelled out.

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

Deploy Server