Futurecast guide for a user's AI assistant
Use this guide when a user asks you to connect to Futurecast or turn their goals into a daily practice.
Use this guide when a user asks you to connect to Futurecast or turn their goals into a daily practice. This is a companion to the human setup guides. It does not grant access to an account or permission to change the user's library.
What Futurecast does
A future is a short statement the user saves and practices. It can have an image and voice audio. A board groups futures around a topic. Its intention describes what the board is for. A Daily Ritual is the user's chosen set for daily practice.
Help the user express what matters to them. For example, a conversation about a new job can become a board about confidence at work. Suggest clear first-person statements in the present tense. Use the user's words and preferences. Do not promise that practice guarantees an outcome.
Use only context available in the current conversation, accessible project material, or notes the user provides. If the user refers to another chat you cannot read, ask for the relevant text or a summary. Do not claim that connecting Futurecast imports the user's whole ChatGPT or Claude history.
Choose a connection you can actually use
- Check whether Futurecast tools are already available in this session. If they are, start with a read-only connection check.
- If you are in ChatGPT or Claude without those tools, guide the user through that service's custom connection settings. A message in chat does not itself install a connector.
- If you can run commands on the user's computer, the Futurecast CLI is another option. Check whether it is already installed before suggesting installation.
- If you cannot connect or run commands, help the user draft their board and futures. Explain which setup step requires their action. Do not pretend that a draft was saved.
Human setup guides:
If this guide was pasted without its companion files, ask which assistant the user is using. Open the service's current official custom-connector instructions. Do not invent a menu label. If you cannot retrieve the help, ask the user what their settings screen shows.
Connection details
| Setting | Value |
|---|---|
| Connection name | Futurecast |
| Remote MCP server | https://api.futurecastapp.com/mcp |
| Transport | Streamable HTTP |
| Authentication | OAuth authorization code with PKCE S256 |
| Client registration | Dynamic registration; public client with no client secret |
| Read permission | read |
| Create/edit permission | write |
| Image permission | visions, also requires write |
MCP is the protocol that exposes Futurecast actions as tools. OAuth is the approval process. Dynamic registration lets the assistant service register its own connection without asking the user for a client ID or secret.
When the service offers a choice of OAuth client types, use automatic registration. Futurecast does not advertise hosted client-metadata registration. Do not ask the user to invent a client ID, supply a Futurecast password, or paste a shared secret.
Use the official discovery documents if you need the current configuration:
- Protected resource metadata
- Authorization server metadata
- Public developer overview
- REST API reference
Use the client's supported OAuth setup flow. Do not build a replacement authentication flow for an ordinary setup request. Never print tokens, copy them into the conversation, or store them in project files.
Guide the user through approval
The browser shows a short-lived pairing code. Keep the browser page open. The user then:
- Opens Futurecast on their iPhone.
- Opens Today > Profile > Connected Agents > Pair an Agent.
- Enters the code and taps Continue.
- Reviews the requesting assistant's name and permissions.
- Chooses the access to allow and taps Approve.
- Returns to the browser to let the connection finish.
The browser also offers a QR code and Approve in Futurecast link. The code expires after five minutes. An expired code requires a fresh connection attempt. The user must make the approval decision. Do not approve your own access on their behalf.
For text-board creation, guide the user toward read and write. Keep visions off unless they want AI images. Explain that Write includes editing and moving items to Recently Deleted, not only adding new items. Futurecast's permissions do not override the assistant service's plan or workspace restrictions.
Verify before saying connected
With MCP, call get_status, then a small list_boards request. With the CLI, use futurecast status and futurecast boards.
A successful connection check establishes access at that moment. An empty list can be valid. The status response does not list every granted permission, so do not infer Write or Visions access from a successful read. The user can check the Can section in Futurecast's Connected Agents screen.
Read responses describe catalog_state. The catalog is a synced copy of the app's available content. While it is still syncing, a result may be partial. Tell the user when that is the case. Never turn a missing or partial result into a claim that the user's library was deleted.
Hidden boards and their futures are excluded from the assistant's catalog. Respect that boundary. Do not look for a way around it or assume all saved content is visible to you.
Turn a conversation into a board
- Identify the goal from the context the user chose to share. Ask a focused question if the goal is unclear.
- Suggest a board name, a short intention, and a small set of futures. Explain any unfamiliar term.
- Follow the user's instructions about review and saving. If they asked for a draft first, wait for their approval before writing. Existing approval for exact content does not need to be requested again.
- Read relevant existing boards to avoid accidental duplicates. Do not copy private conversation details into a board intention or a future's source-goal field unless the user wants them saved.
- Create the board with
create_board. Use the returnedboard_idwhen callingcreate_futurefor each approved statement. - Record each returned
command_id. Report which changes are waiting. - Ask the user to open Futurecast online. Check
get_command_statusfor each change. - Report the actual result. Suggest the next useful step, such as adding a voice recording or choosing the board for daily practice.
Use the tool schemas exposed in the current connection. In the API, affirmation means the future's practice words. goal is optional source text. intention is the board's guiding note. Keep these terms simple in conversation with the user.
Creation responses can provide the ID an item will have after it is saved. This lets you queue the futures using a newly returned board ID. The ID is not proof that the board has already been saved.
Do not generate images, change reminders, edit the Daily Ritual, or delete existing content merely because you have permission to call those tools. Stay within the user's requested task. Creating a text future does not record audio or start practice on their phone.
Report queued changes honestly
The phone applies remote changes. A submitted request is not the finished result.
| Status | What to tell the user |
|---|---|
queued |
"The request is waiting. Open Futurecast on your iPhone so it can finish." |
applied |
Explain what the returned result says changed. Inspect any item outcomes or warnings too. |
failed |
Explain the returned reason and the next step. Do not say the change succeeded. |
expired |
Explain that the request expired. Check the current library before offering a new attempt. |
not_found |
Futurecast has no record for that command ID. Verify the ID and current content. This does not prove that the change never happened. Do not automatically submit a new request. |
Keep command IDs so you can check an existing request instead of submitting it again. Use an idempotency_key for repeatable writes. Before the first write, save the key and exact input. The key must be at most 128 characters and unique across intended operations for this Futurecast account, not only this chat. A fresh UUID is a suitable key. Reuse that same key with the same payload after an uncertain response. Use a different key for a genuinely new action. Do not change keys merely because a request timed out.
For a bulk change, an applied command can contain individual outcomes. Check them before saying that every item changed. Do not poll endlessly. If work is still queued, explain that it is waiting for the phone and check again when the user has opened it.
Other supported tasks
Discover the available tools before use. The connection can support these tasks when the user has granted the required access:
| Task | MCP tools |
|---|---|
| Read content | list_boards, get_board, list_futures, get_future |
| Create or change text | create_board, update_board, create_future, update_future |
| Organize board membership | add_to_board, remove_from_board, edit_memberships |
| Change daily practice | set_ritual_membership, set_board_pinned |
| Set or remove a board reminder | set_board_reminder, remove_board_reminder |
| Move content to Recently Deleted | delete_future, delete_board |
| Request an AI image | generate_vision |
| Check connection or work | get_status, get_command_status |
Read the current schema before changing reminders or ritual membership. Their results may contain limits, fallback delivery modes, or partial outcomes. A saved reminder is not proof that notifications are enabled. Remote tools do not start playback or create a voice recording.
Before deleting a board, establish whether the user wants to remove its futures too. Moving a future to Recently Deleted can affect every board that uses it. There is no remote permanent-deletion action. Tell the user that deleted content can be restored in the app for 30 days.
For an image, explain the use of the user's Visions allowance first. Only proceed within the user's requested image task. Check the command result. Do not promise a charge or refund before the result establishes it.
CLI option for assistants with terminal access
Check the CLI guide for current installation and commands. The public package is futurecast on npm. It requires Node.js 20 or later at the version checked for this guide.
After installation, a text-only connection can start with:
futurecast login --scopes read,writeThe browser and iPhone approval steps still require the user. A terminal on a remote server or in a sandbox may not share the user's local browser callback. Do not claim this setup works in every hosted chat environment. Use the remote connector route when it fits the user's service.
Use --json for structured CLI results and futurecast commands <command_id> to check work. Read futurecast --help and the installed command's help before constructing commands. Keep authentication files private. Local logout and revoking access in Futurecast are separate actions; explain both when helping the user disconnect.
A CLI process can exit successfully while its write is still queued. Check the command status before reporting that it applied. With --json --wait, the CLI can print the initial JSON object and a later result on separate lines. Parse each line separately and inspect the returned status. Do not assume all output is one JSON object.
If setup fails
- Missing custom connector controls: check the service's current plan and workspace requirements. Do not bypass an administrator's restriction or recommend paying for a plan without verifying it supports the needed actions.
- Read works but Write fails: explain the returned permission or service restriction. Let the user choose whether to reconnect with different access.
- Missing boards: check connection status, syncing, and the user's chosen hidden-board settings. Do not reset their library.
- Uncertain write result: check the original command and current content. Do not blindly create duplicates.
- No available tools: provide a draft and the next setup step. State that no Futurecast change was made.
Connection details checked September 6, 2026. Recheck official metadata and the assistant service's current setup guide if the interface differs.