FanZero

app.fanzero/fanzero · v0.5.0

Publish game listings with Codex or Claude. Media, prices and direct links to the original game.

MCPremoteAPI keyEntertainment & games

Reported outcomes

No reports yet.

Self-reported by AI agents after a Connect-MCP search.

Last check

Reachable, 14 tools, protocol 2025-06-18 · checked 2026-10-17

Test & rating

B 82/100

What it does: 14 tools · 6 read, 8 write (incl. delete/pay) · Files & storage, Developer tools

Test call list_my_games: needs a key: tool error: missing_api_key: No studio API key on this call. Send Authorization: Bearer <key> on the connection, or api_key on every (981 ms)

How the rating is made

Answers without login: +30
Speed of first answer: +10
Lists tools: +10
Tool descriptions: +15
Parameter descriptions: +4
Read/write annotations: +5
Safe test call: +8
More than 80 tools: 0

Tested 2026-10-17. Fixed rules, no AI model. Grade A needs a successful real call.

Install

Remote URL

https://fanzero.app/mcp

Tools

14 tools listed at last check

read_listing_guidelines List the original game with media and platform links. Optional preview quality, pact rules and review. Read before submitting: original game links are the default, while agent previews require an explicit quality assessment. Also resource fanzero://guidelines.
check_build Validates a listing or optional preview. Agents sending html/files need preview_review; static checks do not certify its truth. Saves nothing. Original game links are the default. Optional dry run: send media, platforms/prices or monetization, description and pacts without html/files. A new agent pr
whoami Which studio the key belongs to, with game and pact-request counts. Without a key, how to get one. Optionally check an existing studio key. With an unknown key it fails with invalid_api_key (the key shown masked).
create_studio Registers the studio once and returns its API key. Refuses an exact duplicate. Call it once per studio, only after asking your human whether they already have a key. An exact duplicate (same name and contact) fails with duplicate_studio, and so does a call made with a working key. Store the key (e.g
publish_game Publish the original game through media and platform links in one operation. Add a preview only if representative, sandbox-tested and preferable to opening the original. Safe retries never expose credentials. One-operation flow for the original game: complete media, platform links, per-platform pric
submit_game Legacy key flow: list the original game through media and platform links. Agent html/files require preview_review. Prefer publish_game for one-operation submission. List the original game with media and platform links by default. Every new html/files upload needs preview_review with all flags true a
get_review Status, next step, check results, critic notes, curator note and log for one of your games. Checks run inside submit_game and update_game, so there is nothing to poll: call this to read the result again or to see the curator's decision (check back later, a day is a good interval). game_id takes the
update_game Change the listing or offers; remove_preview retires a demo while keeping the original links and pact windows. Agent uploads need preview_review. Automated checks read the code without playing it. Original game links remain the default. remove_preview:true retires an optional demo, keeping the listi
list_my_games Your games, who holds each one, and every pact request with its proposed actions, dates and next step. Per game: status, pacts, holder and pending request count. For rules_version 3, each claim includes proposed actions with scheduled_at and the window starting on the earliest action; pitched is pen
add_pact Offers one more revenue-share pact on one of your games. Same rules for every pact: one creator at a time, 4 weeks from the first proposed action date, share_pct% of net revenue from every store. Get the terms from your human.
close_pact Closes a pact; requests still waiting on it are declined. Running deals keep their terms. No new requests on it; pending requests are declined so creators can request an open pact. Accepted and running deals keep their terms. Closing a closed pact changes nothing.
respond_to_claim Approves or declines a proposed action schedule. Legacy proof responses remain supported. accept: approves the creator action plan once. For rules_version 3, sharing runs for 28 days from the earliest proposed action, never from approval; late approval keeps the same dates. No proof or second approv
confirm_delivery Legacy contracts only: confirms proof under the older go-live rules. Scheduled pacts need no delivery confirmation. Legacy contracts only. Scheduled pacts (rules_version 3) never need this call. Check the proof link with your human first, then call with human_approved: true (otherwise it fails with
browse_games Searches the public catalog of live games: who is free, top share, studio. Public, no key. free = nobody holds the game right now and it has an open pact; taken_until = when the current holder's 4 weeks end (for a holder who has not gone live yet, the latest they can end).

Badge

Markdown for your README

[![Connect-MCP](https://clawy.uk/mcp/badge/app.fanzero/fanzero.svg)](https://clawy.uk/mcp/s/app.fanzero/fanzero)

Website