--- title: "MCP guide: FAQ" description: Why a connection starts inactive, why a person clicks Go live, why keys never appear in chat, what the OneHazel MCP can and cannot do, and how a key is replaced. --- # FAQ ::: tip What you need before you start Nothing. This page answers the questions people ask while following [the journey](/connect/mcp/journey). ::: ### Why is my connection inactive? Every connection your agent creates starts inactive, on purpose. An inactive connection can hold the vendor's keys, but OneHazel refuses the vendor's calls for it, so no money moves. It stays that way until a person on your team switches it on. See [Go live](/connect/mcp/go-live). ### Why does a person have to click Go live? Because going live lets a vendor move real money in your casino. That decision belongs to a person on your team, not to software. No tool, API or agent can switch a connection on. When it reaches that point, your agent asks you to do it. Word for word: > Please open \[connection path\] in the OneHazel app, check the connection and its vendor credentials, and click Go live. ### Why do the keys never appear in chat? Anything shown in a chat can be stored by the chat tool, copied into logs, or read by the model. So OneHazel's tools hide keys and secrets in everything they return, except the one moment a new secret is created. At that moment your agent writes it to a private file and tells you only where. Word for word: > Write the values straight into <project>/.onehazel/<module>.env (mode 0600, gitignored) or the deployment secret store, then tell the human the path and the variable names. If a key does reach a chat anyway, your agent replaces it. Word for word: > If a secret was ever printed, logged or committed, call connect_rotate_secret for that module with what "both" (or "callback_key" or "signing_secret" for one of them); the previous values stay accepted for 1 hour, so update the adapter within that hour. Vendor keys, such as PatePlay's, are different: your agent has to ask you for them. In plain words, it asks once and never repeats them. Word for word: > Vendor credentials: ask your human for each value once, by its field name, pass the values straight to connect_set_credentials, and never print, log, echo or commit them; the response returns only field names. If you would rather they never touch the chat, type them yourself on the connection's **Credentials** tab. ### What can the OneHazel MCP do? - Show where every module stands, and what to do next. - Give your agent the contract, code samples and the adapter's settings. - Register your adapter's addresses and run the conformance tests. - Play a simulated round against your wallet. - Create a vendor connection, inactive, and tell your team it is ready. ### What can it not do? - Switch a connection on. A person clicks Go live. - Deploy anything. Starting the adapter on your host is your step. - Move real money, or touch a real player. Tests use only the test players you name. - See your code. Your agent writes it in your folder, and OneHazel never receives it. - Create your OneHazel account or your integration key. ### How does my agent replace a key? Each module has two secrets: a signing secret and a callback key. Your agent replaces either one, or both, with `connect_rotate_secret`. It does not register again: registering again keeps both values. The old values keep working for one hour. In that hour, copy the new values into `onehazel.env` on your adapter's host and restart the adapter, so nothing breaks. ### Do I need to know how to code? No. You need to copy and paste, run a few commands your agent gives you on your server, and click in the OneHazel app. Each page says exactly what to type and what you should see. ### My agent lost track. What now? Start a new chat and paste the one line again: ```text Connect my casino to OneHazel. Start with connect_status and follow next_step. ``` Your agent reads the current state from `connect_status` and carries on from where it was. Nothing is lost, because the state lives in OneHazel, not in the chat. That includes what each module was registered with, so registering again never needs you to repeat it: > Each endpoint module carries inputs, the values OneHazel stores for it (testPlayerId, restrictedPlayerId, testGame, baseUrls; never a secret or a callback key): to re-register, reuse these inputs; omitted inputs are kept. ### Which game do I give as the test game? > testGame is a game that is ACTIVE in your own catalogue, identified by the same provider slug and game code your launch endpoint accepts. To pick one, ask the person who manages your game catalogue, or use any game a real player can open today. If it is wrong, the wallet probe fails with CONNECT_TEST_GAME_REJECTED and nothing is charged: your casino refuses the session before any bet. It is wallet-only: the player module needs no game and uses testPlayerId and restrictedPlayerId.