Resources
Tools
The errand loop
start_task’s optional note
start_task takes an optional note: something the user wants kept in mind for this errand and
future ones, in their own words — “always pick the cheapest cancellation date”, “never call before
10am”. Hence keeps it against the member who asked and recalls it when a later errand runs. It is
context, not fact: nothing in a note becomes something Hence knows about the household, and a
number in one is re-checked on the page before it is used. A note is also never shown to a step the
user had to approve — that step acts on what was approved and nothing else — so a standing
instruction shapes how an errand reads and navigates, never a consequential act.
Never put an account, card or identity number in a note. One carrying a value of that shape is
dropped whole rather than stored with the number stripped out — and the check errs towards
dropping: any run of eight or more digits is refused, grouped by spaces or hyphens or not, with a
written date the one exempt shape. A note is a standing instruction, so keep long numbers out of
it and put the specifics in objective or inputs.
Events and watches
These are live. A host that would rather not acknowledge anything can still reach a finished task by callingget_task or list_tasks on its own schedule.
Two ways to run the same errand
Plain tools. Any host that can call a remote MCP tool can run every errand:start_task, poll
get_task, relay each pending question in your own voice, return the answer with answer_task.
A result never carries image bytes: a screenshot of a signed-in page stays on our side, and the
structured receipt is the receipt. It does not yet carry a reference to one either — that is the
unbuilt half named above.
Nothing an errand needs is reserved for richer hosts. The questions Hence will not take through a
host — an account number, a routing number, a one-time code, a password — are refused the same way
from every host: answer_task says no and says why. For an account or routing number,
get_task also returns a single-use link to Hence’s own page for you to hand to the user; ask for
it once, because one link stays live per question and a second call inside its window tells you the
first one still works rather than issuing another. A one-time code or password is not collected
through the tool today — get_task says so and names the errand as one that cannot go on, so do not
poll for a link. A host that declares URL-mode elicitation gets the same link delivered as an
elicitation instead; it is a richer delivery, not a second path.
Extensions. A host that declares them gets the errand as a durable task handle with
input_required, elicitation for questions and approvals — form mode for data points and two-value
answers, URL mode for anything sensitive — and the task card as an inline view.
Refusals you should expect to handle
- Not admissible.
admitrefuses with the condition that fired. Show it; it is information for the user, not an error. - Not enabled for this account. Every tool refuses cleanly while access is off. The connection is healthy; do not re-run the OAuth flow, and do not retry in a loop.
- Ceiling reached. An errand that hits its published ceiling returns READY with the remaining action named. That is a successful result, not a failure.