GetMattered

Reply to an Employer Email

getmattered_reply_to_email

Destructive

Sends the user's reply to an employer from their GetMattered address. It cannot be undone.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "message_id": "<message_id>",
      "body": "<body>"
    },
    "name": "getmattered_reply_to_email"
  }
}

Input Schema

Name	Required	Description
`body`	Yes	The exact plain-text reply the user approved, signed with their name. Up to 50,000 characters.
`message_id`	Yes	The message_id of the email to answer, from getmattered_get_inbox. The reply goes to the newest email the employer sent in that conversation.
`confirm_token`	No	The token from a previous call that returned confirmation_required, valid once the user said yes to that exact email, with the same arguments. It works once, for 10 minutes.

Output Schema

Name	Required	Description
`sentAt`	Yes
`status`	Yes	sent: the email went out; not_confirmed: the user declined, nothing was sent; confirmation_required: nothing was sent yet, and the email goes out with confirmToken after the user's yes.
`toEmail`	Yes
`messageId`	Yes	The email that was answered.
`setupStep`	No	Present while account setup is open: the first setup step.
`fromAddress`	Yes
`confirmToken`	Yes	With confirmation_required: the confirm_token value that sends this reply, with the same message_id and body, after the user's yes. Works once, for 10 minutes.
`sentMessageId`	Yes	The sent reply in the inbox. Null when nothing was sent.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 8, 2026

changedOutput schema / properties / confirmToken / description

Previous value: -"With confirmation_required: pass as confirm_token, with the same message_id and body, once the user says yes. Works once, for 10 minutes."New value: +"With confirmation_required: the confirm_token value that sends this reply, with the same message_id and body, after the user's yes. Works once, for 10 minutes."

changedOutput schema / properties / setupStep / description

Previous value: -"Set while account setup is open: the step to take first."New value: +"Present while account setup is open: the first setup step."

changedOutput schema / properties / status / description

Previous value: -"sent: the email went out; not_confirmed: the user declined, nothing was sent; confirmation_required: nothing was sent yet, show the user the email and send it with confirmToken after their yes."New value: +"sent: the email went out; not_confirmed: the user declined, nothing was sent; confirmation_required: nothing was sent yet, and the email goes out with confirmToken after the user's yes."

Changed1 schema field changedNov 8, 2026

changedInput schema / properties / confirm_token / description

Previous value: -"The token from a previous call that returned confirmation_required. Pass it only after the user said yes to that exact email, with the same arguments. It works once, for 10 minutes."New value: +"The token from a previous call that returned confirmation_required, valid once the user said yes to that exact email, with the same arguments. It works once, for 10 minutes."

Changed1 schema field changedNov 6, 2026

addedOutput schema / properties / setupStep

Added value: +{
+  "description": "Set while account setup is open: the step to take first.",
+  "type": "string"
+}

Changed5 schema fields changedOct 31, 2026

addedInput schema / properties / confirm_token

Added value: +{
+  "description": "The token from a previous call that returned confirmation_required. Pass it only after the user said yes to that exact email, with the same arguments. It works once, for 10 minutes.",
+  "format": "uuid",
+  "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+  "type": "string"
+}

addedOutput schema / properties / confirmToken

Added value: +{
+  "description": "With confirmation_required: pass as confirm_token, with the same message_id and body, once the user says yes. Works once, for 10 minutes.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

changedOutput schema / properties / status / description

Previous value: -"sent: the email went out; not_confirmed: the user declined, nothing was sent."New value: +"sent: the email went out; not_confirmed: the user declined, nothing was sent; confirmation_required: nothing was sent yet, show the user the email and send it with confirmToken after their yes."

changedOutput schema / properties / status / enum

Previous value: -[
-  "sent",
-  "not_confirmed"
-]New value: +[
+  "sent",
+  "not_confirmed",
+  "confirmation_required"
+]

changedOutput schema / required

Previous value: -[
-  "status",
-  "messageId",
-  "sentMessageId",
-  "toEmail",
-  "fromAddress",
-  "sentAt"
-]New value: +[
+  "status",
+  "messageId",
+  "sentMessageId",
+  "toEmail",
+  "fromAddress",
+  "sentAt",
+  "confirmToken"
+]

First observedOct 24, 2026

TDQS

B3.4/5.0

Behavior3/5

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

The annotations already declare destructiveHint=true and idempotentHint=false, so "It cannot be undone" largely restates structured data. It could have added value by describing the confirmation_required token flow or delivery semantics, but instead leaves that to the schema.

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?

Two short sentences with the action front-loaded and the irreversibility warning placed second. Nothing is padded, though the second sentence duplicates an annotation rather than earning new understanding.

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

Completeness3/5

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

An output schema exists and the input schema is fully documented, so return values and parameters need no coverage. For an irreversible outbound send, though, the description omits the two-step confirmation workflow and any guidance on verifying the recipient before calling.

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%, and the parameter descriptions are detailed (message_id source, body approval/signature, confirm_token lifetime and single use). The description adds no parameter meaning beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it "sends the user's reply to an employer from their GetMattered address." That is clear and concrete, but it never names or contrasts with the nearest sibling, getmattered_send_follow_up, leaving the agent to infer which send path applies.

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

Usage Guidelines3/5

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

Usage is only implied by the resource named (replying to an employer email); there is no explicit when-to-use, no when-not-to-use, and no mention of the confirmation step. An agent gets the general context but no routing rule against the other outbound-email siblings.

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

All GetMattered tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.