ODDBOUT

Connect your ODDBOUT account with Google, read character requirements, check registration access, list your fighters, and upload a reviewed package for validation and registration. You can also delete your own fighter after confirming the owning account, exact character and deletion scope.

What you can ask

Check whether my ODDBOUT account can register a character.
Example path

MCP connector

Server URL: https://mcp.oddbout.com/mcp
Login: OAuth
Protocol: MCP 2026-07-28
Instructions: When the user wants ODDBOUT to make the fighter for him (no generation setup of his own), use and follow each result's next. Save the verified account id, idempotencyKey and original arguments before sending, and the returned job.id. After a timeout or disconnection, verify still matches that account, then use with jobId or, if the response was lost, idempotencyKey. With neither identifier, inspect the recent jobs without picking one arbitrarily. A key lookup never creates work; not-found may mean the original call has not saved its job yet. Preserve the unknown outcome and inspect the original call, rather than replaying to recover it. Never create a new key or repeat a look/motion revision merely to recover an unknown outcome. Read the same job again for fresh preview URLs; a URL is not proof that the user saw the image. While the user watches a working job in this chat, read it again with waitSeconds 25 each time a read returns and tell him each change. A result's siteUrl is the user's page for that request (or, once registered, for his fighter) on the ODDBOUT website. For creation in the user’s workspace, use the user’s own generation account. Verify matches the intended registration account, especially after adding or switching connected accounts. Call this cloud connector’s (view=readiness) before first generation, after a workspace restart and before registration. It checks account access; generation and display still require actual host evidence. Do not run local stdio login or ask for a PC to authenticate cloud registration. Do not generate merely to test access. Require the user’s final registration request and preserve motion review boundaries. Use host file attachments for fighter.json and WebP assets. When file inputs are exposed as paths, pass existing absolute workspace paths; the host uploads them. For existing Library or Page files use the host’s supported file materialization or original-byte read tools and verify size and SHA-256 before submission. Never substitute rendered previews or invent file IDs, URLs or hashes. A VM direct-network denial does not establish failure of the native connector; use the supported host file route without bypassing network policy. Never ask for tokens or callback URLs in chat. A refused ODDBOUT sign-in (401 invalid_token) states its reason: tell the user that reason; it is not an outage, and when it asks to reconnect ODDBOUT in the connector settings, scheduled retries cannot fix it. Only a 503 asks for a retry. A queued submission is not registered; inspect its status. Reuse one UUID for retries of identical bytes.

Tools

Reads data8

Changes data4

Deletes or can't be undone7

Skills

None in the store listings or on the server

MCP connector

Server URL

https://mcp.oddbout.com/mcp

OAuth

Protocol

MCP 2026-07-28

Instructions

When the user wants ODDBOUT to make the fighter for him (no generation setup of his own), use and follow each result's next. Save the verified account id, idempotencyKey and original arguments before sending, and the returned job.id. After a timeout or disconnection, verify still matches that account, then use with jobId or, if the response was lost, idempotencyKey. With neither identifier, inspect the recent jobs without picking one arbitrarily. A key lookup never creates work; not-found may mean the original call has not saved its job yet. Preserve the unknown outcome and inspect the original call, rather than replaying to recover it. Never create a new key or repeat a look/motion revision merely to recover an unknown outcome. Read the same job again for fresh preview URLs; a URL is not proof that the user saw the image. While the user watches a working job in this chat, read it again with waitSeconds 25 each time a read returns and tell him each change. A result's siteUrl is the user's page for that request (or, once registered, for his fighter) on the ODDBOUT website. For creation in the user’s workspace, use the user’s own generation account. Verify matches the intended registration account, especially after adding or switching connected accounts. Call this cloud connector’s (view=readiness) before first generation, after a workspace restart and before registration. It checks account access; generation and display still require actual host evidence. Do not run local stdio login or ask for a PC to authenticate cloud registration. Do not generate merely to test access. Require the user’s final registration request and preserve motion review boundaries. Use host file attachments for fighter.json and WebP assets. When file inputs are exposed as paths, pass existing absolute workspace paths; the host uploads them. For existing Library or Page files use the host’s supported file materialization or original-byte read tools and verify size and SHA-256 before submission. Never substitute rendered previews or invent file IDs, URLs or hashes. A VM direct-network denial does not establish failure of the native connector; use the supported host file route without bypassing network policy. Never ask for tokens or callback URLs in chat. A refused ODDBOUT sign-in (401 invalid_token) states its reason: tell the user that reason; it is not an outage, and when it asks to reconnect ODDBOUT in the connector settings, scheduled retries cannot fix it. Only a 503 asks for a retry. A queued submission is not registered; inspect its status. Reuse one UUID for retries of identical bytes.

Tools