# Choose the right Domino surface

Domino exposes the same product capabilities through several interfaces, but the interaction mechanics are intentionally different.

## Decision table

| Situation | Surface | What the assistant should do |
| --- | --- | --- |
| The user is looking at letsdomino.io and asks where to click | Web | Give current UI instructions. Do not replace them with API calls. |
| The user is texting Domino or asks what to text | SMS | Give conversational examples and explain follow-up or exact confirmation. |
| The assistant has an authorized Domino MCP connection | MCP | Discover authorized tools, use typed inputs, and present typed outcomes. |
| A developer is building a direct integration | API | Use the generated OpenAPI schema and typed outcome contract. |
| The user asks only “How do I…?” | Usually web instructions | Explain first. Do not infer authorization to act. |
| The user explicitly asks a connected assistant to do it | MCP or API | Execute only within the granted abilities and stop at approval boundaries. |

## Outcome parity, not identical mechanics

“Create an Ideas List” can be one outcome across surfaces:

- on **web**, the user selects **Ideas**, chooses defaults, and submits the form;
- over **SMS**, Domino interprets the request conversationally and asks for missing information;
- through **MCP**, the calling assistant selects and invokes the typed capability;
- through **API**, the caller supplies the structured capability input.

Do not make the surfaces sound identical. They share domain rules and outcomes, not button labels, confirmation syntax, or transport behavior.

For a complete outcome comparison, use [Feature support by surface](/docs/reference/surface-support.md). If the requested behavior is absent or partially supported, use [Limits, unsupported behavior, and current boundaries](/docs/reference/limits-and-current-behavior.md) rather than inferring parity.

## Tell versus do

Classify the user's request before proceeding:

- **Explain:** “How do I share this list?” Give instructions.
- **Prepare:** “Get this ready to share.” Create only a reviewable draft or prepared action when connected and authorized.
- **Commit:** “Send the reviewed invitation now.” Commit only if the relevant surface has a current valid approval.

When uncertain whether the user wants an explanation or an account mutation, ask one direct question. Do not turn a documentation question into a write.

## Surface boundaries

### Web

The user owns every click. Point to visible labels and explain the completion state. A web share-link flow can create a link without sending it through the user's outside messaging app.

### SMS

Domino owns conversational interpretation and durable continuation. Exact control messages can have special meaning. An entire eligible message equal to `SEND` is the external-send confirmation; “yes,” “send it,” punctuation, and extra text are not equivalent.

### MCP

The calling assistant owns natural-language interpretation. Domino exposes authorized typed tools and does not run a second conversational model inside the MCP call. Use handles and returned next actions rather than internal IDs.

### API

The caller supplies strict structured input. Writes require idempotency. Accepted work may require polling. Prepared actions require later same-principal, same-surface commit.

## LLM answering guidance

- State which surface your answer applies to.
- If the user switches surfaces, fetch the new surface guide.
- Never instruct an API or MCP caller to use SMS `SEND` as its approval protocol.
- Never imply that reading a guide grants access to a Domino account.