# Connect FlashBoards here — action-first setup guide

## Start the task: send this message with the file

Uploading a guide alone may be treated as supplying reference material. To request setup, paste this into the chat alongside the attachment, or send it as the next message:

> Connect FlashBoards in this conversation now using the attached guide. First check whether native FlashBoards get_account is available here; if available, call it once and verify success without showing private account details. If missing, carry out the supported setup steps you can perform in this client and give me one concrete next action for anything requiring my input. Keep this conversation as the destination; do not hand off to another mode, app, or host without asking. Do not generate media, change boards, create API keys, purchase credits, or expose credentials. Start with the access check, not a summary of this guide.

For a different intended destination, name it explicitly in that message. Do not infer authorization from a bare attachment when the user has not requested setup; a request to review or summarize the guide is not a connection request.

## First response after the user requests setup

1. **Act on the request now.** Use the current conversation as the default destination unless the user names another. Do not ask whether they want setup, a review, or a summary after they have asked to connect.
2. **Make the read-only access check immediately.** If this session has native tool search/discovery, search for FlashBoards `get_account` and invoke it once if available. This check does not need a filesystem edit or an app switch. Do not delay it solely because the exact desktop/web build is unknown. If discovery is unavailable, state that limitation rather than claiming to have checked.
3. **If access is missing, advance the matching setup path.** Inspect the relevant client controls/configuration using available authorized tools and perform supported non-secret setup steps yourself. Preserve existing entries. Check the host/configuration boundary before any write; do not hand off to gain a terminal.
4. **If the user must act, give exactly one concrete action.** For an established ChatGPT web destination, for example: “Open ChatGPT Plugins, select the plus button, and choose Add custom MCP server. Tell me if that control is absent.” For an uninspectable desktop interface: “Open this app's Settings and tell me whether it has Apps, Plugins, or MCP servers.” Select the action from the observed state and matching recipe; do not recite every alternative or invent menu availability.
5. **Ask only the blocking question.** Ask about the destination only if the user request conflicts or the next setup action genuinely requires a distinction that cannot be discovered. Keep login, consent, permission changes, and destination changes as explicit user handoffs. Once the user returns, continue at that step rather than restarting the interview.

Your first response should contain a real tool action, verified success, or one actionable blocker/handoff. An acknowledgment, guide summary, or promise to check later is not setup progress. Do not claim a tool was called when it was not.

## Destination and safety boundary

Keep the user's original app and chat surface as the destination. Do not hand off to Work, Codex, another app, or another execution host just to gain setup tools. First establish the destination; then check native access there. If that destination is unclear, ask one question before writing configuration. A coding integration being available does not mean the user wants a coding-client connection.

## Connection details

| Field | Value |
| --- | --- |
| Name | FlashBoards |
| Configuration identifier | `flashboards` |
| Server URL | `https://flashboards.yaroflasher.com/api/mcp` |
| Transport | Streamable HTTP |
| Interactive authentication | Browser OAuth, where supported |
| Verification | Native `get_account`, with no arguments, in the intended destination |

No local FlashBoards server is needed. Opening a board is not required to connect or run `get_account`. A signed-in board tab is needed later for live-board operations.

## 1. Lock the destination before setup

- The user's stated destination takes precedence over a model name, available coding tool, installed CLI, or an agent-authored handoff. If the request began in ChatGPT Chat, do not reinterpret it as Codex setup because a continuation says “Codex Desktop.” Ask whether the user approved that change if the instructions conflict.
- Identify both the app and surface: for example, ChatGPT Chat versus Work, ChatGPT web versus a desktop build, Claude Desktop Chat versus Claude Code, or an IDE's particular agent extension. A terminal in a sandbox is not proof that it configures the user's device.
- If unclear, ask: **“Where should FlashBoards be usable: this ChatGPT conversation, ChatGPT in your browser, or a Codex/Work session?”** Adapt this question to the actual ambiguity. Do not ask it when the user has already specified the destination.
- Do not switch app, mode, host, or profile without the user's explicit agreement. A request to connect FlashBoards does not itself authorize a mode handoff.
- Do not create or alter configuration until its relationship to the chosen destination is established. A shared configuration is relevant only when the actual client build and host use it.

## 2. Check existing access in that destination

Search its native/deferred tools for `FlashBoards get_account`. If available, call it once and inspect an authenticated result. If search is empty, make one targeted discovery retry using `get_account authenticated account`, then inspect connection state if possible.

Do not transfer the task to another runtime merely to perform this search. A connector badge, remembered name, saved entry, tool list, or read performed by another client does not prove access in the requested conversation.

If connected, stop. Otherwise follow only the matching recipe. Reuse an existing FlashBoards entry, preserve unrelated settings, and avoid duplicate registrations. Keep public instructions in English.

## 3. Choose the matching client

### ChatGPT app or ChatGPT web — read this before the Codex recipe

Keep the user's ChatGPT destination. Do not infer that the presence of `com.openai.codex`, a Work integration, or a terminal authorizes changing it.

**If the user is in the ChatGPT desktop app:**

1. Check whether FlashBoards tools are already usable in the requested Chat conversation.
2. If missing, establish which MCP/app controls this installed build actually exposes. Current OpenAI documentation describes some desktop builds sharing Codex-host MCP configuration, but that does not establish support or menu availability in the user's installed build or requested mode.
3. If the user says **“MCP servers is not in Settings,” accept that observation.** Do not repeat that menu path or automatically prescribe `codex mcp login`. Ask only for the relevant settings view or app version if needed, without requesting private account information.
4. If no matching setup surface can be established, offer the documented ChatGPT web Plugins route below and ask before changing destination. Say: **“I cannot verify custom MCP setup in this desktop build. May we configure and verify it in ChatGPT web instead?”** Do not label the desktop destination configured based on a Codex entry.
5. If the user specifically wants a verified Codex-host desktop/Work integration, use the Codex recipe only after confirming that destination. A successful Work tool call must be reported as Work access, not proof of access in the original Chat conversation.

**For an agreed ChatGPT web destination:**

1. Use the same intended ChatGPT account/workspace. Open [ChatGPT Plugins](https://chatgpt.com/plugins) > plus button > **Add custom MCP server**. Do not change unrelated security settings.
2. Enter **FlashBoards**, the server URL above, and **OAuth**. Use dynamic client registration where offered; do not invent a client ID or client secret. Review the risk warning with the user and, if approved, choose **Create as a plugin**. Complete connection prompts and let the user finish FlashBoards sign-in and review/approve OAuth consent. Review the discovered tools.
3. Install the resulting plugin if prompted, then check whether FlashBoards is available with **@** in the original intended web chat. If available, select it and run native `get_account` there; select it again when a follow-up requires another tool call. If unavailable, state that access in that chat is unverified and ask before moving to a new conversation, as the official verification guide describes. **Try in chat** starts a separate conversation; use it only if that is the agreed destination or the user approves a fresh-chat fallback. Do not use a local Codex command to verify hosted ChatGPT access.
4. If the account shows the legacy Apps interface instead, follow its observed **Apps > Create** or **Workspace settings > Apps > Create** controls. Do not prescribe missing settings or send the user through every UI variant. Availability and administrator permissions vary; stop at a missing permission.

This creates a private custom MCP connection presented as a plugin, not an OpenAI-reviewed public directory listing. It does not bypass account/workspace permissions or replace FlashBoards OAuth consent. Do not publish an app to the workspace merely to test it. Report only settings actually observed.

**Old failed ChatGPT connectors:** The historical FlashBoards OAuth fix corrected new public-client registration. An affected pre-fix failed connector may need deletion and recreation. Ask before resetting that connector, complete fresh OAuth, and never replay failed authorization codes. Do not apply this reset to working connections or unrelated discovery/network failures.

Sources: [Connect and test in ChatGPT](https://developers.openai.com/plugins/deploy/connect-chatgpt), [workspace permissions and app setup](https://help.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt), [current local-host MCP documentation](https://learn.chatgpt.com/docs/extend/mcp).

### Claude Desktop Chat or Claude web — direct-link setup first

Keep the original Claude conversation as the verification destination. Do not switch to Claude Code or add a local Desktop JSON bridge. Opening the browser for this Claude account setup/OAuth flow does not mean moving the task to a different chat; return to the original conversation afterward.

1. **Check native access here first.** If `get_account` is available, call it once and stop on success. If an existing FlashBoards connector is known, reuse or reconnect it; do not create a duplicate. An empty tool search alone does not establish that no saved connector exists.
2. **Use the prefilled setup link before manual settings navigation.** If setup is needed, show the clickable link below as the next action. If authorized browser controls are available, you may open it for the user instead. Say whether you actually opened it; displaying a link is not an executed browser action. Do not search the public connector directory as a prerequisite: this is a custom-connector flow and requires no listing.

[Connect FlashBoards to Claude](https://claude.ai/customize/connectors?modal=add-custom-connector&connectorName=FlashBoards&connectorUrl=https%3A%2F%2Fflashboards.yaroflasher.com%2Fapi%2Fmcp)

3. **Check the form before adding.** In the same intended Claude account/workspace, the link should open **Add custom connector** with name **FlashBoards** and URL **https://flashboards.yaroflasher.com/api/mcp**. Claude may show a notice to verify externally supplied values. Inspect them with browser tools, or ask the user whether the fields are filled correctly. Check for an existing entry before creating another; if one exists, use its connection controls instead. Do not claim prefill success from the URL alone.
4. **Finish supported setup, then hand off consent.** Use the observed **Add**/**Connect** controls, performing non-secret steps with authorized browser tools where supported. Keep detected authentication settings. Where offered, use **Sign in now** and **Register automatically**. Leave optional client ID, client secret, and headers empty; do not invent credentials. Let the user complete login and review/approve OAuth consent when prompted. Do not assert that all setup clicks must be manual merely because consent requires the user.
5. **Return and verify here.** After the user confirms approval, retry native discovery in the original Claude conversation. Enable/select FlashBoards in that chat if necessary. Call `get_account` once, inspect authenticated success, and report without private account fields. Do not restart or demand a fresh chat by default. If the current conversation still lacks tools, report that exact blocker before proposing a fresh-chat test.

**Suggested first response after an unsuccessful native access check:**

> FlashBoards is not available to call in this chat yet. [Open the prefilled FlashBoards connection form](https://claude.ai/customize/connectors?modal=add-custom-connector&connectorName=FlashBoards&connectorUrl=https%3A%2F%2Fflashboards.yaroflasher.com%2Fapi%2Fmcp). Tell me whether the FlashBoards name and server URL are already filled in; do not add a duplicate if FlashBoards is already connected to this account.

Use that response only after actually checking available native discovery. If no discovery tool exists, say so instead of claiming a check occurred. When browser automation can inspect the form, do that rather than asking the user to describe it.

**Fallback only after an observed problem:**

- If Claude requires login, let the user sign in to the intended account, then reopen the same link if needed.
- If the link does not open the add form or the values are not prefilled, record that result. Use **Customize > Connectors > + > Add custom connector**, or the installed version's observed equivalent, and enter the exact name/URL manually. Treat this as a fallback, not a successful direct-link test.
- If an administrator must add connectors, stop at that permission handoff. Do not switch accounts/workspaces or alter organization policy.
- If an existing entry is disconnected, reconnect it instead of adding another. If it already works, preserve it; testing a link is not permission to reset a working connector.

**Setup status to report:** form opened, name prefilled, URL prefilled, existing/new entry, manual fallback used or not, OAuth completed or not, and native `get_account` success in the original chat or the exact blocker. Record unobserved stages as unknown. Do not preserve credentials, callback URLs, or account payloads.

The link opens a browser-based Claude account setup flow, not a silent install or a native-app deep link. Browser sign-in, form availability, account permissions, and user-controlled OAuth consent still apply. Inspect the displayed name and URL; the link alone does not prove setup or access.

Sources: [Prefill parameter reference](https://github.com/anthropics/claude-ai-mcp/issues/74#issuecomment-4436078150), [official Claude setup](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp).

### Claude Code — only when this is the destination

Inspect `/mcp` first. For a missing personal connection, run on the actual Claude Code host:

```bash
claude mcp add --scope user --transport http flashboards https://flashboards.yaroflasher.com/api/mcp
```

Open `/mcp`, select FlashBoards, authenticate if requested, and verify in that Code session. This does not configure Desktop Chat.

[Official Claude Code MCP documentation](https://code.claude.com/docs/en/mcp)

### Cursor editor

Use native MCP management under **Customize** or the route exposed by the installed version. For personal access, merge only this entry into `~/.cursor/mcp.json`:

```json
{
  "mcpServers": {
    "flashboards": {
      "url": "https://flashboards.yaroflasher.com/api/mcp"
    }
  }
}
```

Save, enable/connect, complete browser OAuth, and verify in the intended agent chat. Use project `.cursor/mcp.json` only for requested project scope. Local editor setup does not establish Cloud Agent access.

[Official Cursor MCP documentation](https://cursor.com/docs/mcp)

### VS Code with built-in MCP / Copilot

Use Command Palette **MCP: Add Server > HTTP**, enter the URL and `flashboards`, and choose the intended user/profile target. Remote sessions may need remote configuration. Use **MCP: List Servers** to start/authenticate, select the tool in chat, and verify there. Third-party agent extensions can have separate configuration.

[Official VS Code MCP configuration](https://code.visualstudio.com/docs/agents/reference/mcp-configuration)

### Codex CLI or confirmed Codex-host desktop/IDE session

This recipe is not a fallback for a ChatGPT Chat request. Use it only for the user's chosen, established Codex-host destination. Do not infer that an arbitrary sandbox or exposed coding integration owns the user's local configuration.

Inspect the existing FlashBoards entry without printing secrets. For a missing personal connection on that host:

```bash
codex mcp add flashboards --url https://flashboards.yaroflasher.com/api/mcp
```

If authentication is required, use native login once:

```bash
codex mcp login flashboards
```

Use **MCP servers**, **Add server**, or **Authenticate** UI actions only when present in this exact app. Follow an explicit restart prompt if shown; do not invent one. Verify in the requested Codex-host session. Local configuration does not configure hosted ChatGPT web.

**If login fails before a browser opens:**

- State that OAuth has not completed; do not ask the user to approve a consent page that was never observed.
- Inspect the actual sanitized error and its stage. Distinguish configuration-write denial, sandbox network denial, DNS/TLS/HTTP failure, OAuth metadata/registration rejection, and callback failure. The phrase “OAuth discovery failed” alone does not identify the cause.
- A generic HTTP response from the server does not prove the native client's discovery/login path works. Another client's successful OAuth test does not diagnose this failure.
- Do not repeat the same failed command or offer a nonexistent settings menu as recovery. A retry needs an observed change, an explicit retry instruction, or a justified transient-error policy.
- Ask the user to run the CLI in their own terminal only when this is still the agreed Codex destination and there is evidence that the agent's execution environment is the blocker. Explain that reason and that success would establish Codex access, not hosted ChatGPT access. Otherwise stop with the exact blocker and request the sanitized error needed to investigate.

[Official local-host MCP documentation](https://learn.chatgpt.com/docs/extend/mcp)

### Hermes

Target the active profile and execution host, not automatically the default `~/.hermes` directory. For a missing entry, use the native CLI in that profile context:

```bash
hermes mcp add flashboards --url https://flashboards.yaroflasher.com/api/mcp --auth oauth
```

Complete native browser authorization. Use `/reload-mcp` in the intended session if tools have not refreshed, then verify. For an existing entry needing authentication, use its native login action rather than adding a duplicate. Remote backends need a supported remote OAuth flow, not a custom public callback bridge.

[Official Hermes MCP documentation](https://hermes-agent.nousresearch.com/docs/user-guide/features/mcp)

### Other clients

Check that exact product's current remote-MCP and authentication instructions. Configuration keys are not interchangeable. Use Streamable HTTP, not a legacy SSE fallback. If unsupported, report the limitation and offer one alternative without switching clients yourself.

## 4. API-key fallback — only when appropriate

Use this only for an agreed client without compatible OAuth, an unattended runtime, or an explicit API-key request—not to conceal an unexplained OAuth failure.

- Have the user create a dedicated key in FlashBoards **Settings > Developer** and enter it directly into the client's secure storage or approved secret manager, never chat.
- Use the client's documented secret reference for Bearer authorization. A terminal variable may not reach a desktop app or remote host; check availability without printing its value.
- Never put secrets in command arguments, committed files, URLs, or logs. Do not layer a Bearer header over OAuth without an agreed authentication change.

## 5. Verify in the original or explicitly agreed destination

After approval, retry native discovery and call `get_account`. Inspect an authenticated account result, not an MCP error. Stop after success. Never substitute HTTP probes, `tools/list`, an agent's summary, or another runtime's result.

Do not generate media, edit boards, create keys through tools, purchase credits, publish integrations, install software, or alter unrelated connections as part of verification. Read-only MCP avoids generation charges, but client/model usage can still be billed; obtain approval before new paid API tests.

Use one accurate status:

- **Connected in [verified destination].** Native `get_account` succeeded. No generations or board changes were performed.
- **Configured in [verified host], not authenticated.** [Observed login failure.] This does not establish access in [original destination, if different]. Next: [one evidence-based action].
- **Authentication completed, native access not verified in [destination].** Next: [check tool selection/discovery in that destination].
- **Not configured in [destination].** [Missing control, permission, or unresolved host.] Next: [one question or supported handoff requiring user agreement].

Use “this session” instead of inventing an app identity, but never use it to hide an unapproved handoff. Do not repeat email, IDs, roles, balances, or raw account responses. The client's own tool transcript may retain private values.