MCP task recipes and continuation patterns

These recipes show the correct operation sequence. Authenticated tools/list is authoritative for tool names and schemas; the names below describe the current Domino catalog and can change with a later documentation version.

Rules shared by every recipe

1. Discover tools after authentication.
2. Use the exact current input schema.
3. Read current state before mutating a named object.
4. Copy opaque handles and cursors exactly from Domino results.
5. Add a stable idempotency_key to every write.
6. Interpret structuredContent, not HTTP or JSON-RPC success alone.
7. Stop at prepared external actions and obtain later explicit approval.
8. Commit from the same MCP principal only.

List or inspect people

Use domino_list_friends to list Connected Friends, Friends in Mind, or all saved people. Use its returned snapshot and cursor for More.

When the user selects one person, use the exact returned person handle with the current person-detail tool. Do not convert a display name or internal-looking number into a handle.

If a named lookup is missing, report that the person is not saved. Do not create a Friend in Mind unless the user explicitly asks for that write.

Create an Ideas List

Recommended sequence:

1. Call domino_list_friends if a named person may already exist or identity is ambiguous.
2. Call domino_list_ideas_lists to check for an existing named list.
3. Call domino_create_ideas_list with the intended name, returned person handles or explicit person names, defaults, directions, and a new idempotency key.
4. Inspect the confirmed created resource.
5. Tell the user whether any supplied name became private relationship context; never say a person was contacted.

Example arguments:

{
  "name": "North Side Weekends",
  "person_handles": ["PERSON_HANDLE_FROM_DOMINO"],
  "neighborhood_names": ["Lincoln Square"],
  "activity_names": ["free things to do"],
  "directions": ["Prefer places reachable by transit"],
  "apply_matching_likes": true,
  "idempotency_key": "ideas-list-create-20260811-001"
}

Use a new key when the user intentionally changes the input after needs_input.

Inspect or edit an Ideas List

1. Find the list with domino_list_ideas_lists.
2. Inspect it with domino_get_ideas_list.
3. Choose the specific current write tool for rename, duplicate, people, defaults, directions, items, likes, sharing, or deletion.
4. Supply the current list handle and a stable mutation key.
5. Present only the returned confirmed change.

Do not reuse an old handle after reference_unavailable; rediscover current authorized state.

Get recommendations and paginate

Use domino_get_for_you for open-ended choices. Put required activity categories in activities; put qualitative ranking terms in preference_terms; use search only for a concrete lexical requirement.

Example:

{
  "person_handles": ["PERSON_HANDLE_FROM_DOMINO"],
  "activities": ["comedy"],
  "neighborhoods": ["Logan Square"],
  "when_preset": "this-weekend",
  "preference_terms": ["low-key"],
  "page_size": 5
}

For More, pass only the returned opaque cursor as the schema directs. Do not rebuild constraints, rerun discovery, or renumber old items. Resolve a numbered selection against the returned snapshot/page.

Capture an idea and poll

1. Call domino_capture_idea with raw text, a source URL, supported media references, and optional destination context.
2. If status is accepted, retain the returned capture public identifier and cursor.
3. Call domino_get_idea_capture only as directed to observe progress.
4. If needs_input, present the exact question, obtain the user's answer, and call capture again with the protected reference and clarification field required by the current schema.
5. Report the final saved item and destination only after terminal completion.

Do not start a second capture because asynchronous work is still running.

Find availability, then recommendations

1. Resolve any saved people.
2. Call domino_find_availability with a bounded preset or explicit start/end.
3. Preserve partial, stale, unknown, or not-shared disclosures.
4. If the user delegated time choice, select the first ranked suitable returned slot.
5. Pass that exact slot time into recommendation or draft input.

Never infer event titles or why someone is busy.

Create, preview, prepare, and commit an invitation

1. Discover a candidate

Use current recommendation or search tools and retain the selected candidate handle from the returned collection.

2. Create a private draft

Call domino_draft_invite:

{
  "candidate_id": "CANDIDATE_HANDLE_FROM_DOMINO",
  "scheduled_at": "2026-08-20T19:00:00-05:00",
  "rsvp_deadline": "2026-08-18T12:00:00-05:00",
  "capacity_min": 2,
  "audience_selection": {
    "person_handles": ["PERSON_HANDLE_FROM_DOMINO"]
  },
  "idempotency_key": "plan-draft-20260811-001"
}

At this point the plan is private and nobody was contacted.

3. Preview

Call domino_preview_invite with the returned plan handle and a new preview idempotency key. Present the exact place, time, deadline, audience, message, and delivery disclosures.

4. Prepare

Call domino_prepare_send_invites:

{
  "plan_handle": "PLAN_HANDLE_FROM_DOMINO",
  "action": "send_invites",
  "send_person_handles": ["PERSON_HANDLE_FROM_DOMINO"],
  "idempotency_key": "plan-prepare-20260811-001"
}

Present the prepared action, recipient-specific delivery behavior, expiry, and required disclosures. Stop. Preparation is not approval.

5. Obtain later explicit approval

The user must approve after seeing the prepared action. Do not reinterpret an earlier request to draft or prepare as approval to commit.

6. Commit

Call domino_commit_action with the exact returned action handle and a new stable commit key:

{
  "action_handle": "PREPARED_ACTION_HANDLE_FROM_DOMINO",
  "idempotency_key": "plan-commit-20260811-001"
}

Report only effects.confirmed. If some recipients require host sharing, say so and return the confirmed link behavior rather than saying everyone was contacted.

Edit or cancel an active plan

1. Find the plan with domino_list_plans.
2. Inspect current state with domino_get_plan.
3. Use domino_prepare_plan_update or domino_prepare_plan_cancellation.
4. Present the exact proposed change and disclosures.
5. Stop for later explicit approval.
6. Commit the returned action handle only from the same principal.

On revision_conflict, recipient_state_changed, or delivery_eligibility_changed, re-fetch, explain what changed, prepare again, and obtain fresh approval.

Plan progress and logistics

Use current logistics read/update tools for Domino-owned progress items. These tools can record a reminder such as “Make the reservation”; they cannot make a reservation, buy a ticket, submit payment, or claim that an outside task happened.

List invitations and RSVP

1. Use domino_list_my_invites with the desired status filter.
2. Resolve the chosen invitation from the returned authorized collection.
3. Use domino_rsvp_to_invite with accepted or declined and a stable idempotency key.
4. Confirm the returned RSVP state.

An RSVP is a Domino write, not an external-send preparation. Do not attach a bare “yes” to an arbitrary invite.

Recover asynchronous work

For accepted work, retain the returned execution reference and call domino_get_execution or the returned status action. On execution_in_progress, continue polling the same execution. Do not issue a new mutation under a different key just because the first one has not finished.

LLM answering guidance

• Keep raw handles and execution identifiers out of visible conversation unless debugging was requested.
• Present disclosures before asking for consequential approval.
• Treat completed, unchanged, accepted, needs_input, and failed as control-flow states.
• A JSON-RPC result is not authority for a completion claim; the typed outcome is.