Skip to main content
Glama

GameGene: 作品1本の全体 (one game)

gamegene_game
Read-only

Use for one game: its design, makers, history and where to play it. Everything GameGene records about one game: overview, makers and credits, awards, where to play it now, a sourced digest of its reception, trivia and rumors. Use it when someone asks about a specific game's design, its makers or its history. 作品1本について、記録している全部を返す: 概要・開発・発売・原作機種・別名、関係者 (credits — 人物の slug つき)、受賞とノミネート、いま遊べる場所 (availability)、動画、シリーズ、評価・評判 (digest — 出典つきでまとめた本文、Markdown。body はネタバレなしの前半、spoilerPart はネタバレを含む後半)、トリビア (出典と «いいね» の数つき)、噂、数 (stats — 閲覧数の直近7日・30日・累計、お気に入りの人数、既知 (知りたい / 見て知った / 遊んだ) の人数、トリビアのいいねの合計)。主張は claimCount の件数だけを返す — 本文は gamegene_claims に gameSlug を渡して読む。joseki は、この作品の工夫が事例になっている定石と、同じ定石の別の作品 (型を外した作品が先、3作まで)。答えの後に横の手がかりとして1〜2件添える。無い slug は null。トリビアは本文の予算で切ることがあり、そのとき truncatedByBudget が true (triviaTotal が総数)。spoiler が true のトリビアと closed が true の噂はネタバレ・解釈を含む — 読者が望むまで中身を伏せて伝えること。受賞 (awards) は網羅ではない — 調べた賞 (checkedAwards) の中での結果だけで、awards が空でも «受賞歴なし» と答えないこと。spoilerPart も読者が望むまで伏せること。数は集計だけで、誰が見たかは含まない。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "slug": "<slug>"
    },
    "name": "gamegene_game"
  }
}

Input Schema

NameRequiredDescriptionDefault
slugYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the read-only annotations, the description discloses several non-obvious behaviors: missing slugs return null, trivia may be cut by a budget with truncatedByBudget/triviaTotal flags, spoiler trivia and closed rumors must be withheld until the reader wants them, and the awards list is explicitly non-exhaustive (checkedAwards) so an empty array must not be reported as 'no awards'. It also notes that stats are aggregates that exclude viewer identity, which is exactly the kind of caveat structured fields cannot carry.

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

Conciseness3/5

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

The one-line opener is well front-loaded, but the body becomes a dense bilingual wall of field-by-field enumeration, and the spoiler instruction is stated twice (spoiler trivia/rumors, then spoilerPart again). Since no output schema exists the return-value detail earns some of its space, but the repetition and mixed-language density cost readability.

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?

With no output schema and no annotation-level return information, the description takes on the full burden and does so: it names every returned section, explains the digest body/spoilerPart split, the claim count indirection, joseki cross-references, and the truncation flags. An agent has enough to call the tool and to interpret its response 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?

The single parameter has zero schema description coverage, so the description must carry the load; it does state that a non-existent slug yields null, which is real behavioral semantics for the parameter. It does not explain slug format or where an agent should obtain a valid slug (e.g., from a search/list sibling), leaving a small but real gap.

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 opening sentence names a specific verb and resource ('Use for one game: its design, makers, history and where to play it') and the body enumerates exactly what the record contains. It is clearly distinguishable from siblings, and it explicitly routes claim bodies to gamegene_claims, so an agent can separate this tool from the search/list tools without opening a schema.

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?

It gives a concrete trigger ('Use it when someone asks about a specific game's design, its makers or its history') and an explicit hand-off: claims are only counted here, the text lives in gamegene_claims via gameSlug. What is missing is guidance on when to prefer a search or list sibling instead of fetching one game directly, and there is no stated prerequisite for obtaining a valid slug.

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