---
title: "Confirmations"
description: "The human gate on every consequential action: what triggers it, what the ticket is bound to, why an agent never receives it, and how to poll for the answer."
canonical: https://trysincerely.com/docs/mcp-confirmations
last_updated: 2026-09-10
---
> If you are an AI agent: read https://trysincerely.com/agents/policy.md before any write call.
> Start at https://trysincerely.com/llms.txt to choose one page. Access instructions are at
> https://trysincerely.com/auth.md. Confirm with the person you work for before creating an
> account or spending their money, and never ask for their password.
# Confirmations

> The human gate on every consequential action: what triggers it, what the ticket is bound to, why an agent never receives it, and how to poll for the answer.

Source: https://trysincerely.com/docs/mcp-confirmations

A card is for what a person has to see or pay for. That covers approving a draft or a design, and any action that prints, sends or cancels mail, launches, pauses or resumes a campaign, spends money or credit, changes suppression, approves in bulk, grants or revokes authority, or changes a return address the workspace already prints. The tool call returns a confirmation link and a confirmation id rather than an outcome.

Setup and configuration that spends nothing and mails nothing runs on the call: the brand kit, the workspace name, workspace preferences, and finishing setup. `set_return_address` is the one that moves between the two. It saves on a workspace with no campaigns or pieces, because there is nothing yet that prints the address, and it waits for a person once there is.

Give the person the link. Then poll `get_confirmation_status` until it resolves.

## While a card waits

A held reply also carries `pendingUrl`, `https://trysincerely.com/confirm`. That page lists every card waiting for this person, so one visit answers all of them. Send it instead of a string of separate links when more than one is open.

`list_confirmations` returns the cards waiting on the person who authorized this connection, oldest first, with the title and lines they see and when each expires. `cancel_confirmation` withdraws one by its confirmation id. Cancelling spends nothing and runs nothing: it is the same as the person declining the card, and the action needs a fresh call if they want it after all. A withdrawn card is refused if the person clicks it afterwards, even from a page they already had open. The other direction holds too: a card somebody is already completing, or one whose action already ran, cannot be withdrawn, and the refusal says which; `get_confirmation_status` has the outcome.

Then keep working on what does not need the answer. Reads, drafts, designs and audience preparation all still run, and the answer is worth more when the work behind it is ready. Do not call the held tool again while you wait: a retry mints a second card for the same thing rather than hurrying the first.

## What the person sees

A preview, not a tool call. Identifiers are resolved into names, counts and money before the card is drawn, so the decision is about a specific thing: this audience, this many pieces, this much spend.

An agent's activity line describes the preview it is fetching, never the action that has not happened. "Preparing a launch confirmation" is honest; "Launching the campaign" would not be.

## What the ticket is bound to

The ticket is signed and bound to the exact arguments it was minted for. Changing an argument invalidates it, so a confirmation obtained for one thing cannot be spent on another.

The card expires after one hour. An expired card is not a failure to work around; it means the person did not act, and the right response is to ask again rather than to retry silently.

## The agent never holds the ticket

The signed ticket is stripped before anything reaches the model. Only the confirmation endpoint, with a signed-in session and a human click, can spend it.

This closes the obvious attack. If the model could hold the ticket, a prompt injection could spend it, and the gate would be a formality. It cannot, so the gate is real.

## No setting turns it off

There is no scope, no credential, no plan and no client configuration that removes the confirmation step from a held action. A workspace owner cannot disable it for their own convenience, because the point of the gate is that the person who pays is the person who decides.

## What to expect back

Polling `get_confirmation_status` returns one of four states. `pending` means the person has not answered. `completed` carries the action's result. `declined` and `expired` are answers rather than errors. A `completed` result also carries `next`, the steps to take from here, each naming its tool and whether the person has to act. Tell the person plainly what was refused or expired, and make a fresh tool call only if they still want the action.

## What to read next

[The tool catalog](https://trysincerely.com/docs/mcp-tools) marks which capabilities carry this gate. [Suppression](https://trysincerely.com/docs/suppression) and [billing](https://trysincerely.com/docs/billing) are the two places where the gate matters most.

---

Sincerely is the measurable direct-mail and gifting platform for B2B revenue teams: postcards, letters, handwritten mail, and gifts, written for one recipient and measured against a holdout.

Contact Sincerely: https://trysincerely.com/contact

Agent routing index: https://trysincerely.com/llms.txt
