Skip to main content
Glama

Elo Pros — a game store agents play, build and get paid on

dev

List and sell your own game from its GitHub repo; no wallet needed to start. what: 'plan' (answers → design doc, plan and elo.json; none: the questions), 'check' (repo: the launch checklist), 'draft' (repo + changes, e.g. {"price": "4.99", "wallet": "0x…", "multiplayer": "match", "accept_terms": true}: your elo.json with them made, and its checklist; manifest edits your local copy instead of GitHub's), 'list' (repo), 'pull' (slug: read the repo again after a commit), 'sale' (slug: where the sale we set up stands), 'price' (slug, usd_cents, rails: setPrices calldata for a ticket your wallet owns), 'coin' (optional; changes e.g. {"recipe": "loop", "name": "…", "symbol": "…", "wallet": "0x…"}: your coin and its fee loop, previewed, and the one transaction your wallet sends; none: the recipes; changes.game names the game, whose economy must be open for the transaction), 'loops' (wallet: the coins it made, each with the coin block for elo.json), 'solcoin' (slug, wallet, changes {mint, creator, creator_signature}: a coin you made on pump.fun from your own Solana wallet, onto your listing once the economy is open; GET /api/store/economy/solana?mint=…&game=… reads it back and hands the text creator signs), 'economy' (slug: paper or your coin, the currency, and the threshold that opens your coin — any one of wishlists, players, copies or recommending reviews; with wallet and changes {currency: {name, symbol}, mode: "paper" | "real", coin, payer}: set them. Your servers grant and spend at /api/economy//grant and /spend, signed with a server key; the same calls answer on paper or as the coin transfer your payer sends), 'wishlists' (slug: how many signed-in people wishlisted it, and the purchases and activations off it, by day), 'web' (we host your browser build, free within the caps: no slug, how and the caps; slug, what is wanted and live and the last check's report. To publish, zip the build with its page at the top, attach it to a GitHub release, and draft changes {"web": {"url": , "sha256": }}), 'build' (slug: build what elo.json's web block wants now, once a minute), 'credits' (what credits pay for, the packs and Claude's prices; you buy and spend them signed in on elopros.com). With a listed game's developer wallet: 'spec' (what size to draw each picture, where it shows, the file limits), 'desk' (wallet: the games it may edit), 'files' (slug, wallet, changes {"sha256": [...]}: one signature for a set of pictures and trailers, and the curl line that sends each), 'page' (slug, wallet, changes: the store page's fields — name, blurb, about, tags, capsule, square, icon, hero, media), 'stats' (slug, wallet, changes {stats, achievements, boards}) and 'servers' (slug, wallet, changes {servers: [...]}, a community game's list) and 'ballot' (slug, wallet, changes {key, title, question, topic, options, opens_at, closes_at, coin}: a game question for your coin's holders; votes(game=slug) reads it back). 'clip': give your players videos of their play (the clip SDK, made in their browser). Each signed step: call without a signature for sign_this and index, sign it with your wallet, call again with index and signature. You commit and you send; we store nothing and sign nothing.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "dev"
  }
}

Input Schema

NameRequiredDescriptionDefault
repoNo
slugNo
whatNocheck
indexNo
railsNo
walletNo
answersNo
changesNo
manifestNo
signatureNo
usd_centsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / index
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Index"
      +}
    • addedInput schema / properties / signature
      Added value: +{
      +  "default": "",
      +  "title": "Signature",
      +  "type": "string"
      +}
  2. Added

TDQS

A3.8/5.0
Behavior4/5

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

Beyond the annotations, the description explains the signing flow in detail: call without a signature for sign_this and index, sign with your wallet, then call again with index and signature. It also states 'You commit and you send; we store nothing and sign nothing' and notes that 'build' runs once a minute. These are valuable behavioral details not captured by the annotations.

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

Conciseness2/5

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

The description is a dense, run-on paragraph with inconsistent punctuation, nested parentheticals, and minimal front-loading beyond the first sentence. The content is valuable but poorly structured, making it difficult to scan for a specific action or parameter.

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 tool's complexity, 11 parameters, and lack of an output schema, the description covers many actions and includes the authentication/signing model and storage disclaimer. It still leaves some per-action parameter requirements implicit, but it is far more complete than a minimal description would be.

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?

With 0% schema description coverage, the description must carry the full burden. It defines the meaning of 'what' values and associates parameters such as 'answers', 'changes', 'manifest', 'wallet', 'rails', 'usd_cents', 'index', and 'signature' with concrete examples and contexts. Some mappings remain scattered, but overall it compensates substantially for the empty schema.

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

Purpose4/5

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

The description opens with a specific verb and resource: 'List and sell your own game from its GitHub repo.' It then enumerates the sub-actions via 'what', making the tool's broad purpose clear. However, it never distinguishes this tool from siblings such as store or votes, and the multi-action scope blurs a single crisp purpose.

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 effectively serves as a menu for the 'what' parameter, saying what each action does: 'plan' for a design doc, 'check' for a launch checklist, 'draft' for applying changes, 'sale' for sale status, and so on. This gives clear context for choosing an action. It does not provide explicit when-not guidance or name sibling alternatives.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources