What can you do with this server?

This MCP server lets you manage Scorezilla leaderboards directly from your AI coding assistant — from provisioning resources to generating integration code and reading live standings. List & Inspect * list_games — View all games on your developer account (id, slug, name, creation date). * list_boards — Inspect all boards under a game (ranking direction, score type, retention, bounds). Read Leaderboard Data * get_board_top_n — Fetch the top 1–100 ranked entries on any board. * get_keys — Retrieve public API keys (safe to embed) and secret key prefixes; full secrets are never exposed over MCP. Generate Integration Code * get_sdk_snippet — Get ready-to-paste SDK code tailored to your setup, configurable by: * Identity strategy (anonymous, OAuth, server-authoritative, etc.) * Hosting/anti-cheat pattern (client-only, client-with-server, server-only) * Server language (TypeScript, Python, Go, C#) * OAuth providers (Google, GitHub, Supabase, Firebase, Clerk, Auth0, etc.) Create & Configure * bootstrap_leaderboard — Create a new game + board in one call, receiving a widget HTML embed, SDK snippet, and plain-English recommendations. * create_game / create_board — Create games or boards independently, with full control over sorting direction (high-score or lowest-time), score kind (integer, float, duration_ms), retention, and score bounds. * mint_key — Generate a fresh public/secret API key pair for any game (secret shown once). * update_board_config — Modify score bounds and retention on an existing board. * update_game_config — Update origin allowlists for a game. Read-Only Mode: Pass --read-only to disable all write tools for safe use in shared or CI environments.

Which integrations are available for this server?

Allows using GitHub as an OAuth provider for player identity in leaderboards, enabling score submissions with GitHub authentication.

scorezilla-mcp

by isco-tec

Overview Schema Related Servers Score Discussions

TypeScript

Remote

scorezilla-mcp

npm version license: MIT

Official Model Context Protocol (MCP) server for Scorezilla — the easiest way to add a leaderboard to your game. Connect this server to your AI coding assistant (Claude Code, Cursor, Continue.dev, …) and ship a working leaderboard without leaving your editor.

What you can ask the AI to do

"Add a leaderboard to my game" → it bootstraps a game + board and pastes ready-to-run TypeScript SDK code into your project
"What did my last test score rank?" → it reads your live leaderboard
"List my games" / "show me the boards on X" → it inspects what you already have

Eleven tools total — five read-only, and six that write: four that create resources (bootstrap_leaderboard, create_game, create_board, mint_key) plus two that update config (update_board_config — score bounds + retention, e.g. an anti-cheat maxScore; update_game_config — the browser-submit origin allowlist).

Related MCP server: @exerciseapi/mcp-server

Install + configure

Status — v0.3.0. Published on the @latest dist-tag. 0.3.0 adds three create-only write tools — create_game, create_board, mint_key — so an agent can provision against an existing game (add boards, mint keys, create more games), not just bootstrap a brand-new one. 0.2.0 added the integration-axis arguments (identity strategy, OAuth provider, hosting/anti-cheat pattern, server language) to bootstrap_leaderboard + get_sdk_snippet. Destructive ops (edit/delete, key revocation) remain dashboard-only by design.

1. Get a token

Sign in at dashboard.scorezilla.dev, open MCP tokens, click Create token. Copy the mcp_live_* value once — it's not shown again.

2. Add the server to your AI coding assistant

Claude Code — edit ~/.claude/settings.json:

{
  "mcpServers": {
    "scorezilla": {
      "command": "npx",
      "args": ["-y", "@scorezilla/mcp"],
      "env": {
        "SCOREZILLA_TOKEN": "mcp_live_…"
      }
    }
  }
}

🔒 Keep ~/.claude/settings.json private. The token is stored in plaintext in that file. Make sure it's not committed to git (it's usually in your .gitignore), not synced to a public dotfiles repo, and not backed up to a shared location. On macOS/Linux: chmod 600 ~/.claude/settings.json so only your user can read it. If a token leaks, revoke it at dashboard.scorezilla.dev/account/tokens.

Cursor — open Settings → Features → MCP → Add new MCP server, then use the same command + args + env shape.

Anything else MCP-compatible — point your client at npx -y @scorezilla/mcp with SCOREZILLA_TOKEN set in the environment.

3. Ask away

In Claude Code or Cursor: "Add a Scorezilla leaderboard to this game."

Tools

Tool	What it does
`list_games`	Lists your games. Use this first to orient.
`list_boards`	Lists leaderboards under a game.
`get_keys`	Returns the public key (safe to embed) and the secret-key prefix. The full secret never leaves the dashboard.
`get_board_top_n`	Returns the top entries on a board. The "is my integration working?" tool.
`get_sdk_snippet`	Returns ready-to-paste integration code for a board. Optional axis args tailor it: anonymous/OAuth identity, client-only vs. server-validated anti-cheat, and the server language (TS/Python/Go/C#).
`bootstrap_leaderboard`	Creates a new game + first board in one call, then returns the widget embed + SDK snippet + a plain-English recommendation. Same optional axis args (anti-cheat, OAuth, server language). The 90-second-demo path.
`create_game`	Creates a new (empty) game. Use when a game already exists (so `bootstrap_leaderboard` would conflict) or you want another.
`create_board`	Adds a leaderboard board to an existing game (by `gameId`), with full options (sortDir, scoreKind, retention, bounds).
`mint_key`	Mints a fresh public/secret key pair for an existing game. The secret is shown once.

Flags

scorezilla-mcp [--read-only] [--base-url=<url>] [--version] [--help]

--read-only — refuse to register the write tools (bootstrap_leaderboard, create_game, create_board, mint_key, update_board_config, update_game_config). Use this on shared/CI configs to guarantee the AI can't create or change resources.
--base-url=<url> — override the API origin. Defaults to https://api.scorezilla.dev. Useful for self-hosted or staging environments.

Env vars

SCOREZILLA_TOKEN — required. Bearer token issued at dashboard.scorezilla.dev/account/tokens.
SCOREZILLA_BASE_URL — same as --base-url, but via env. CLI flag wins if both are set.
SCOREZILLA_BETA_TOKEN — pre-public closed-beta only. When set, sent as the X-MCP-Beta header on every API call to unlock the MCP namespace before the public switch is flipped. You'll only need this if a Scorezilla team member gave you a beta token; ignore otherwise.

Tokens: how they work

Tokens are scoped to the developer who issued them and see every game associated with their account.
The MCP server never returns the secret-key plaintext for a game — for that, copy from the dashboard.
Revoke a token any time at dashboard.scorezilla.dev/account/tokens. Revocations propagate within a few seconds.
Tokens are bearer credentials: anyone with the value can call the API on your behalf. Don't commit them to source; don't paste them into shared chats. Keep them in env blocks, password managers, or secret stores.

Runtime requirements

Node ≥ 20
A network path to https://api.scorezilla.dev

Releasing

Releases are CI-driven and require an approval click in the npm-publish GitHub Environment. The full flow:

Author a changeset locally: pnpm changeset — describes what changed and the bump type. Commit the file under .changeset/.
Merge to main. .github/workflows/release.yml runs and opens a "chore(release): version @scorezilla/mcp" PR that bumps package.json, syncs server.json (the MCP Registry manifest) via scripts/sync-server-json-version.mjs, and updates CHANGELOG.md.
Merge the version PR. The same workflow then publishes:
- npm tarball with --provenance (verifiable build attestation via GH OIDC + sigstore)
- MCP Registry record via mcp-publisher login github-oidc → mcp-publisher publish
- Post-publish smoke test that installs the published tarball and runs the binary
Pre-flight guards that run before publish: typecheck, test, build, bin smoke (node dist/index.js --version), and release:check (asserts package.json and server.json versions agree).

Manual publishes from a developer terminal still work (bash scripts/publish.sh) but aren't the path CI takes — they skip provenance and approval gates. Use only for one-off recovery.

Issues / feedback

GitHub Issues.

License

MIT.

Available Tools

6 tools

bootstrap_leaderboardA

Use this when starting from scratch — creates a new game AND its first board in one call, then returns ready-to-paste integration code wired against the board. The fastest path from "I want a leaderboard" to "scores are flowing." Do NOT call this if the developer already has games — call list_games first and use bootstrap_leaderboard only when no game exists yet. The response includes snippets.sdk (framework/server code), snippets.widget (a themeable drop-in HTML embed; null for server_only), and a plain-English recommendation to relay to the developer — paste snippets.sdk (and/or snippets.widget) into their code. The optional axis args tailor the output: set hostingPattern='client_with_server' for anti-cheat (server-validated scores), playerIdentityStrategy='auth_provider' (+ authProvider) for OAuth identity, or serverLanguage for a non-TypeScript server. Omit them all for the simplest anonymous + client-only setup.

ParametersJSON Schema

Name	Required	Description	Default
`gameName`	Yes	Display name of the game (any string)
`gameSlug`	Yes	URL-safe slug for the game, e.g. "my-racing-game" (2–42 chars, lowercase + hyphens; derive from gameName)
`boardName`	Yes	Display name of the leaderboard
`boardSlug`	Yes	URL-safe slug for the board, e.g. "high-scores" (2–42 chars, lowercase + hyphens)
`sortDir`	No	"desc" for high-scores-win, "asc" for lowest-time-wins	desc
`scoreKind`	No	Score type: integer (default), duration_ms (time trials), or float	integer
`playerIdentityStrategy`	No	How players are attributed. 'anonymous' (default) mints a local UUID, no PII; 'prompted_local' asks once and saves to localStorage; 'auth_provider' uses OAuth (also set authProvider); 'server_authoritative' has the game server attach the playerId (needs hostingPattern client_with_server or server_only); 'custom_callback' for a dev-supplied function.
`authProvider`	No	Required when playerIdentityStrategy is 'auth_provider'. supabase/clerk/auth0/firebase get a server-side JWT-verifying secure-submit endpoint (real anti-cheat); google ships a browser helper; github/apple/discord are planned; custom is the escape hatch.
`hostingPattern`	No	Integrity model. 'client_only' (default): the browser holds the public key — simplest, but NO anti-cheat. 'client_with_server': your server validates + signs scores — use this for competitive boards where cheating matters. 'server_only': server reads/writes and renders SSR HTML (max integrity, SEO-friendly, no widget).
`serverLanguage`	No	Language for the server-side snippet. Required for hostingPattern 'server_only'; optional for 'client_with_server' (defaults to typescript, which gets the turnkey createScoreSubmitHandler endpoint). python/go/csharp return a best-effort snippet.

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully carries the burden. It discloses that it creates a game and board, returns specific snippet fields, and explains how optional parameters alter behavior (e.g., anti-cheat, identity strategy). No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph but front-loads the primary purpose. While dense, every sentence adds value. Could be more structured, but appropriate for the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having 10 parameters and no output schema, the description thoroughly explains the response structure (snippets.sdk, snippets.widget, recommendation) and how each optional parameter affects the output. Complete for a complex tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 100% description coverage, so baseline is 3. The description adds high-level context, like which combination of options yields the 'simplest anonymous + client-only setup', enhancing understanding beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a new game and its first board in one call, returns integration code, and distinguishes itself from sibling tools by specifying 'when starting from scratch' and not to call if games already exist.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says to use when starting from scratch and not to call if developer already has games, with an alternative action ('call list_games first'). Provides clear context for decision-making.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_board_top_nA

Get the top-ranked entries on a leaderboard. Call this after the developer submits a test score to confirm the integration is wired correctly — they will see their own test entry appear. Also useful for displaying current standings.

ParametersJSON Schema

Name	Required	Description	Default
`boardId`	Yes	UUID of the board
`n`	No	Number of entries to return (1–100). Defaults to 10.

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must cover behavioral traits. It implies a read operation and mentions a testing use case but does not explicitly state read-only nature, authentication needs, rate limits, or error conditions. Falls short of full disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with clear front-loading of purpose. No extraneous words. Every sentence contributes value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks details on output format and error conditions. Given the absence of an output schema, the description could briefly mention the structure of returned entries. Use cases are covered but operational completeness is lacking.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters are already well-documented. The description adds no additional meaning beyond the schema's definitions. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it gets the top-ranked entries on a leaderboard. It distinguishes from siblings like list_boards or bootstrap_leaderboard by specifying leaderboard context and adding specific use cases.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use scenarios: after submitting a test score to verify integration and for displaying standings. However, it does not discuss when not to use or mention alternative tools, which would further aid decision-making.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_keysA

Get a game's API keys. Returns, per key: kind ('public' | 'secret'), prefix, createdAt, and rotation/revocation timestamps. The PUBLIC key includes its full plaintext (it's safe to embed in client code). The SECRET key's plaintext is ALWAYS null over MCP — only its prefix is shown, for identification. Use this to retrieve the public key for a client_only integration, or to check which keys exist / have been revoked. If the developer needs the full SECRET key (for a client_with_server / server_only anti-cheat setup), direct them to https://dashboard.scorezilla.dev — the Keys section under their game — since it never leaves the dashboard.

ParametersJSON Schema

Name	Required	Description	Default
`gameId`	Yes	UUID of the game to fetch keys for (from list_games)

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behavior: it returns public key plaintext, secret key plaintext is always null over MCP, and provides rotation/revocation timestamps. It also warns about what it cannot do (return full secret key). No contradictions with annotations since none exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise yet comprehensive: first sentence states purpose, then describes returned fields, then usage guidance and alternative. Every sentence adds value without fluff. It is front-loaded with the main action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description thoroughly explains what is returned (kind, prefix, timestamps) and what is not (secret key plaintext). It also references the required predecessor tool (list_games) and links to the dashboard for missing functionality, making it complete for the tool's scope.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already describes gameId as 'UUID of the game to fetch keys for (from list_games)' with 100% coverage. The description adds context that gameId comes from list_games, but does not add new information about the parameter itself beyond what the schema provides. Baseline is 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get a game's API keys,' specifying the verb 'Get' and the resource 'API keys'. It differentiates from siblings by focusing on keys, which none of the other tools (bootstrap_leaderboard, get_board_top_n, etc.) cover.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to use this tool: 'to retrieve the public key for a client_only integration, or to check which keys exist / have been revoked.' It also provides an alternative for the full secret key (dashboard). It implies that list_games should be used first to obtain the gameId.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_sdk_snippetA

Call this whenever the developer asks how to submit a score, initialize the SDK, or integrate a leaderboard into their code — INCLUDING when they want a setup other than the default: anti-cheat (server-validated scores), OAuth player identity, or a non-TypeScript server. Returns a ready-to-paste integration snippet (the snippet field) tailored to the axis arguments. Omit the axis args for the simplest anonymous + client-only TypeScript setup; set hostingPattern='client_with_server' (+ a serverLanguage and/or auth provider) for the secure anti-cheat path. Use it right after bootstrap_leaderboard, or any time the developer needs the integration code again or wants to switch approach. (For the drop-in widget HTML embed, bootstrap_leaderboard returns it as snippets.widget.)

ParametersJSON Schema

Name	Required	Description
`gameId`	Yes	UUID of the game
`boardId`	Yes	UUID of the board to target in the snippet
`playerIdentityStrategy`	No	How players are attributed. 'anonymous' (default) mints a local UUID, no PII; 'prompted_local' asks once and saves to localStorage; 'auth_provider' uses OAuth (also set authProvider); 'server_authoritative' has the game server attach the playerId (needs hostingPattern client_with_server or server_only); 'custom_callback' for a dev-supplied function.
`authProvider`	No	Required when playerIdentityStrategy is 'auth_provider'. supabase/clerk/auth0/firebase get a server-side JWT-verifying secure-submit endpoint (real anti-cheat); google ships a browser helper; github/apple/discord are planned; custom is the escape hatch.
`hostingPattern`	No	Integrity model. 'client_only' (default): the browser holds the public key — simplest, but NO anti-cheat. 'client_with_server': your server validates + signs scores — use this for competitive boards where cheating matters. 'server_only': server reads/writes and renders SSR HTML (max integrity, SEO-friendly, no widget).
`serverLanguage`	No	Language for the server-side snippet. Required for hostingPattern 'server_only'; optional for 'client_with_server' (defaults to typescript, which gets the turnkey createScoreSubmitHandler endpoint). python/go/csharp return a best-effort snippet.

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It explains that the tool tailors the snippet based on axis arguments and returns a snippet field. However, it does not disclose side effects, authentication requirements, or rate limits, which would be needed for a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph that effectively conveys key information without unnecessary words. It could be slightly more structured (e.g., bullet points) but is still concise and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (6 params, 4 enums, no output schema), the description covers primary use cases, distinguishes from siblings, and explains what the output contains. It does not mention potential errors or edge cases, but is sufficiently complete for most scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining how omission of axis args leads to simplest setup and gives context for each hostingPattern/playerIdentityStrategy beyond the schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns a ready-to-paste integration snippet for submitting scores, initializing SDK, or integrating a leaderboard. It distinguishes itself from sibling tool bootstrap_leaderboard by noting that the latter returns a drop-in widget HTML embed.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to call: whenever the developer asks about integration, after bootstrap_leaderboard, or anytime they need the code again. Provides guidance on omitting arguments for simplest setup and when to use specific hostingPattern values.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_boardsA

List all leaderboards (boards) under a given game. Each board has its own id, slug, ranking (sortDir: desc = high-score-wins, asc = lowest-time-wins), score kind (integer / duration_ms / float), retention policy, and optional min/max score bounds. Call this to find a board's id before generating a snippet (get_sdk_snippet) or reading standings (get_board_top_n), or to show the developer what boards already exist under a game returned by list_games.

ParametersJSON Schema

Name	Required	Description	Default
`gameId`	Yes	UUID of the game to list boards for (from list_games)

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must disclose behavior. It describes the properties of returned boards but does not mention that it is a read-only operation, any side effects, authorization needs, or rate limits. The absence of such details lowers transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is two well-structured sentences. First sentence states main function. Second sentence provides details and usage context. No redundancy or unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (one parameter, no output schema), the description covers the key aspects: input source, output characteristics, and usage scenarios. It could mention response format (array), but the list of board properties compensates.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers the only parameter with a description. Description adds value by explaining that gameId comes from list_games output, which helps the agent obtain the correct input. This extra context justifies a score above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it lists all leaderboards under a given game, and distinguishes from siblings by explaining its role in finding board IDs before using get_sdk_snippet or get_board_top_n. It also specifies the information each board contains, which provides clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises when to use: to find a board's id before generating a snippet or reading standings, or to show existing boards. It also references list_games as the source of the gameId. However, it does not explicitly state when not to use or compare to all sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_gamesA

List all games owned by the authenticated developer. Returns each game with id, slug, name, and createdAt. Use this first to orient before creating new resources or inspecting an existing game. If the result is an empty list and the developer wants to add a leaderboard, call bootstrap_leaderboard next.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It describes the return structure and scope (owned by authenticated developer), but does not explicitly mention that the operation is read-only and safe. However, the context implies a safe list operation, and the description adds value beyond the name. A minor gap in explicitly stating safety attributes prevents a perfect score.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with the primary action, and every sentence serves a purpose. No wasted words, and it is well-structured for quick parsing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, no output schema), the description fully covers what it does, what it returns (id, slug, name, createdAt), and provides usage context and alternatives. It is complete enough for an AI agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, and the input schema is empty with 100% coverage. The description does not need to add parameter semantics, so a baseline score of 4 is appropriate as per guidelines.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool lists all games owned by the authenticated developer, and distinguishes itself from siblings by suggesting an alternative tool (bootstrap_leaderboard) for a specific scenario. The verb 'list' and resource 'games' are specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states to use this first for orientation before creating or inspecting resources, and provides a conditional guideline: if the result is empty and the developer wants to add a leaderboard, to call bootstrap_leaderboard. This gives clear when-to-use and when-not-to guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.2.0Jun 9, 2026
- First observedbootstrap_leaderboard
- First observedget_board_top_n
- First observedget_keys
- First observedget_sdk_snippet
- First observedlist_boards
- First observedlist_games

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a clear, distinct purpose: creating a game+board, listing games, listing boards, getting top scores, retrieving API keys, and generating integration code. There is no overlap or ambiguity between them.

Naming Consistency4/5

Tool names follow a verb_noun snake_case pattern. While 'bootstrap' is less standard than 'get' or 'list', the overall style is consistent and predictable.

Tool Count5/5

Six tools cover the core aspects of a leaderboard integration service (game management, board listing, score retrieval, key management, snippet generation) without redundancy or gaps.

Completeness4/5

The tool surface covers essential setup and monitoring operations. Missing update/delete operations for games and boards, but these are less critical for the primary use case of integrating a leaderboard.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Lovable
dev.lovable
Official MCP server for Lovable, the AI-powered full-stack app builder.
Developer Tools AI & Machine Learning
23
Subfeed MCP
app.subfeed.mcp
Official MCP server for subfeed.app — the cloud for agents. 15+ tools for AI agents to register, build, and deploy other agents. Zero human required. Start here: subfeed.app/skill.md
Agent Orchestration Cloud Platforms Autonomous Agents
2
agentwork-mcp A
io.github.ferm-ai
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
Agent Orchestration Autonomous Agents App Automation
2
Qase Test Management
io.qase
Official MCP server for Qase — manage test cases, runs, suites, defects via AI tools.
Testing & QA Tools Developer Tools
231

Related MCP Servers

Perplexity API MCP Server
Search AI & Machine Learning
Hanato238
A
license
A
quality
C
maintenance
Official MCP server for the Perplexity API Platform, enabling AI assistants to perform real-time web search, reasoning, and deep research using Sonar models.
Updated 4 months ago (2026-05-02 04:41 UTC)
4
44,116
MIT
@exerciseapi/mcp-server
Health & Wellness Fitness Tracking
westvegh
A
license
Not graded
quality
D
maintenance
Official MCP server for exerciseapi.dev — give your AI coding agent direct access to 2,198+ vetted exercises across 12 categories.
Updated 5 months ago (2026-04-14 01:25 UTC)
43
2
MIT
Nhost MCP Serverofficial
Cloud Platforms Databases Developer Tools
nhost
A
license
Not graded
quality
F
maintenance
Official MCP server for the Nhost backend platform. Manage Postgres data, GraphQL, auth, storage, migrations and Hasura metadata via AI assistants.
Updated 10 months ago (2025-10-27 04:31 UTC)
5
MIT
lacuna-mcp
Audio Processing AI & Machine Learning
JOYLINK-LTD
A
license
Not graded
quality
B
maintenance
Official MCP server for the Lacuna Music API. Generate AI music — full songs with vocals and lyrics, or instrumentals — with style prompts, task status polling, and audio downloads.
Updated a month ago (2026-08-10 06:48 UTC)
4
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/isco-tec/scorezilla-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

scorezilla-mcp

What you can ask the AI to do

Install + configure

1. Get a token

2. Add the server to your AI coding assistant

3. Ask away

Tools

Flags

Env vars

Tokens: how they work

Runtime requirements

Releasing

Issues / feedback

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Nhost MCP Serverofficial

Latest Blog Posts

MCP directory API