Servidor MCP de FanZero

• Nome no registroapp.fanzero/fanzeroverificado no registro MCP

O nome no registro fica sob fanzero.app. O registro só libera esse espaço de nomes para quem prova controle do domínio por DNS ou HTTP.

• Estadorespondeverificado em 2026-10-27
• Ferramentas15
• O servidor se chamafanzero
• Versão do servidor0.5.0
• Versão do protocolo2025-06-18

Em 2026-10-27 o servidor respondeu a initialize e tools/list sem login. Primeira resposta em 243 ms.

• Ainda não avaliamos se as ferramentas fazem o trabalho do produto.
• Verificado em 1 dos 7 dias necessários para julgar a confiabilidade.

Dito por regras a partir das medições acima. A primeira chamada provável é a escolha de um modelo na lista de ferramentas; leia a descrição antes de confiar nela.

• Nota INITE MCPdepois de uma semanaa nota precisa de 7 verificações diárias: 1 até agora
• Respondeumedindo1 das 7 verificações diárias necessárias para mostrar a porcentagem
• Mediana da primeira resposta412 ms
• Espaço no contexto do agente≈ 10.233 tokensas definições de todas as ferramentas (15), que o agente carrega a cada turno
• Definições das ferramentasA · 90 de 100
• Resultados tipados14 de 15 ferramentasdeclaram outputSchema: o resultado chega tipado e é lido de uma vez

• Parâmetros sem descrição: em 9 de 15

Um programa verifica o servidor uma vez por dia: initialize e tools/list, sem modelo. Os tokens são o tamanho das definições, a cerca de quatro caracteres por token. A nota é a média de seis verificações do nome, da descrição, do esquema e das anotações de cada ferramenta; diz se as ferramentas estão bem descritas, não se funcionam. A nota pesa só o que foi medido: se responde (25%), se faz o trabalho do produto (25%), definições (20%), contexto (10%), uso (10%) e a facilidade de conectar (10%). Uma parte não medida fica de fora, e uma instrução oculta limita a nota a 40. O estado dos servidores MCP dos fornecedores: método e números →

• 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…

• 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…

• 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…

• publish_game

  Publish the original game through media and platform links in one operation. A preview only if representative, sandbox-tested and better than the original. Safe retries never expose credentials. One-operation flow for the original game…

• 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…

• 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…

• update_game

  Change the listing or offers; remove_preview retires a demo, 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…

• 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…

• add_pact

  Offers one more revenue-share pact on one of your games. Same rules for every pact: one influencer 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 influencers can request an open pact. Accepted and running deals keep their terms. Closing a…

• respond_to_claim

  Approves or declines a proposed action schedule. Legacy proof responses remain supported. accept: approves the influencer action plan once. For rules_version 3, sharing runs for 28 days from the earliest proposed action, never from…

• 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…

• submit_settlement

  After a pact window: declares each platform's net revenue, with its own report. The influencer accepts or disputes. After a scheduled pact's window: one line per key in claim.distribution with the net revenue that platform pays or will…

• 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…