Servidor MCP de FanZero

• Nombre en el registroapp.fanzero/fanzeroverificado en el registro MCP

El nombre en el registro está bajo fanzero.app. El registro solo permite usar ese espacio de nombres a quien demuestra control del dominio por DNS o HTTP.

• Estadorespondecomprobado el 2026-10-27
• Herramientas15
• El servidor se llamafanzero
• Versión del servidor0.5.0
• Versión del protocolo2025-06-18

El 2026-10-27 el servidor respondió a initialize y tools/list sin iniciar sesión. Primera respuesta en 243 ms.

• Aún no se ha juzgado si sus herramientas hacen el trabajo del producto.
• Comprobado 1 de los 7 días necesarios para juzgar su fiabilidad.

Lo dicen reglas a partir de las mediciones de arriba. La primera llamada probable la elige un modelo de la lista de herramientas; lee su descripción antes de fiarte.

• Nota INITE MCPtras una semanala nota necesita 7 comprobaciones diarias: 1 hasta ahora
• Respondiómidiendo1 de las 7 comprobaciones diarias necesarias para mostrar el porcentaje
• Mediana de la primera respuesta412 ms
• Espacio en el contexto del agente≈ 10.233 tokenslas definiciones de todas sus herramientas (15), que el agente lleva en cada turno
• Definiciones de herramientasA · 90 de 100
• Resultados tipados14 de 15 herramientasdeclaran outputSchema: el resultado llega tipado y se lee de una vez

• Parámetros sin descripción: en 9 de 15

Un programa comprueba el servidor una vez al día: initialize y tools/list, sin modelo. Los tokens son la longitud de las definiciones, a unos cuatro caracteres por token. La nota promedia seis comprobaciones del nombre, la descripción, el esquema y las anotaciones de cada herramienta; dice lo bien descritas que están, no si funcionan. La nota pondera solo lo medido: si responde (25%), si hace el trabajo del producto (25%), definiciones (20%), contexto (10%), uso (10%) y lo fácil que es conectarse (10%). Lo que no se midió queda fuera, y una instrucción oculta limita la nota a 40. El estado de los servidores MCP de los proveedores: método y 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…