> ## Documentation Index
> Fetch the complete documentation index at: https://docs.usehence.com/llms.txt
> Use this file to discover all available pages before exploring further.

# MCP tools and resources

> The tool surface the Hence execution connector exposes: what each call is for, what it takes, and what comes back.

<Warning>
  **Not live yet.** The execution server at `https://mcp.usehence.com/mcp` is still being built, so
  none of the calls below answer today. This page is the published contract they are being built
  against; the per-call schemas here are generated from the server once it ships, and this page is
  replaced by that generated output.
</Warning>

Everything is reached through one server, over Streamable HTTP, with OAuth 2.1. Adding the server is
covered on the [Connect](/connect/mcp) pages.

## Resources

| Resource               | What it is                                                                                                                                                                                               |
| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `capabilities`         | The generated manifest: every errand's intents, admission conditions, required inputs, published ceiling, blockers and instruments, jurisdiction and freshness. Deterministically ordered and cacheable. |
| `task://…/receipt`     | The receipt for a task or one of its steps — what was requested, of whom, on what date, by what route, what confirmation to expect, and the proof of delivery.                                           |
| `ui://hence/task-card` | An inline card: timeline, links to the screenshots taken, the pending question, approve or decline, receipt. Every card has a text fallback, so a host that cannot render it loses nothing.              |

## Tools

### The errand loop

| Tool          | What it does                                                                                                                                                                 |
| ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `admit`       | Runs an errand's gate against the facts you have. Returns admitted with the inputs still required, or refused with the clause that fired. Call it before promising anything. |
| `start_task`  | Delegates an errand with the facts gathered so far. Returns a durable task id and the first status. The user's Hence profile is read on our side, never through the host.    |
| `get_task`    | Current state, pending input requests, latest update, screenshot references. The baseline path for a host without the tasks extension: poll it.                              |
| `answer_task` | Delivers the user's answer or approval to a pending request. Idempotent on the request id — a duplicate or stale answer is ignored rather than applied twice.                |
| `cancel_task` | Stops a run. Cooperative: it stops at the next safe point.                                                                                                                   |
| `list_tasks`  | The user's open tasks. Also the verification call on every Connect page — an empty list is a healthy connection.                                                             |

### Events and watches

| Tool                                           | What it does                                                                                                                                                                                                                         |
| ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `poll_events`                                  | Everything since a cursor — a task completed, input needed, a watch fired — each with a text summary, a deep link and a hint for when to check again. This is how a host's scheduler reaches a user who has closed the conversation. |
| `create_watch`, `list_watches`, `cancel_watch` | A standing instruction with a kind and parameters. Hence evaluates it on its own schedule and writes an event when it fires. One watch kind exists in the first wave: a new or increased recurring charge.                           |

## 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`.
Results carry **references** to the screenshots, not the image bytes: a screenshot of a signed-in
page stays on our side, and the structured receipt is the receipt. Nothing an errand needs is
reserved for richer hosts.

**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.** `admit` refuses 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.