Skip to main content
Glama

GameGene: 工夫 (design techniques and makers' intent)

gamegene_claims
Read-only

Why a game was designed so: makers' own words on what they did and dropped. 作品の工夫 (設計の判断) を、作り手の狙いと捨てた案・出典つきで返す。Design decisions recorded for games or design genes: what the makers did, why (their stated intent, and the options they rejected when known), where it came from, with sources. Use it to give someone making a game sourced precedents, usually after gamegene_search has found the games. 作品または gene を指定して、記録されている主張を返す。複数の作品・gene は gameSlugs / geneSlugs (各最大30) で1回にまとめて引く — 1件ずつ呼ばない。作品と gene を両方渡すと、どちらかに当たる主張を全部返す (和)。各主張の subjectGameSlug / geneSlug でどれのものか分かる。無い slug は unknownSlugs に入る (在るものだけで引く)。本文を持つのでページングする — nextOffset が null でなければ続きが在る。件数と本文の合計文字数の両方で打ち切り、予算で切れたときは truncatedByBudget が true になる。claimType は invention / integration / refinement / transfer / inversion / scaling / popularization の7種で、transfer と inversion と invention が «新しい組み合わせ» を記録した行である。各主張には evidence が並ぶ — 出典の題・URL・archiveUrl・種別と、その根拠が主張を支持するか反論するか (stance)、どれだけ直接に支えるか (directness)。根拠の抜粋と要約は含まない (応答が膨らむため)。出典を持たない主張では空配列になる。format: "cite" returns a short form for citing precedents in an answer: per claim the game (title, year), text (one language), one supporting source (title, author, year, type, directness, url) and pageUrl, instead of both languages and every source. Prefer it when answering a design question. Cite each precedent as: game (year) — what the makers did and, if the text says so, what they dropped or traded away — source (author, year) — pageUrl. Call it the makers' own words only when source.type is interview or talk and source.directness is direct; otherwise say it is GameGene's reading of the source. Do not state a claim as an established precedent when its status is draft or researching (still being checked) or opposingSources is above 0; say it is unconfirmed or disputed. ai_generated is the normal state of a sourced record. source.author is who wrote or gave the source, not necessarily the person in the claim. joseki (only when the claim is a case of one): the recurring design judgements it follows or breaks, each with up to 3 other games under the same judgement (departure first). After answering, offer one or two of them as cross-genre leads, kept apart from the answer.

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": "gamegene_claims"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo
formatNo
offsetNo
gameSlugNo
geneSlugNo
gameSlugsNo
geneSlugsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / format
      Added value: +{
      +  "enum": [
      +    "full",
      +    "cite"
      +  ],
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover read-only safety; the description adds pagination via nextOffset, budget truncation with truncatedByBudget, unknownSlugs handling, claim types, evidence fields, draft/researching status caveats, and citation constraints. No contradiction with annotations.

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?

Content is dense and purpose is front-loaded, but the same material is repeated in Japanese and English and the description carries many inline rules. Redundancy and length reduce crispness, though most sentences convey operational guidance.

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 and high complexity, the description covers return shape, pagination, evidence structure, citation format, status handling, and joseki guidance. Only minor parameter bounds are missing.

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 coverage, the description explains the plural slug arrays (max 30), union behavior when both are supplied, unknownSlugs, and the format enum. It does not describe limit/offset bounds or the singular gameSlug/geneSlug parameters, leaving some gaps.

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?

Explicitly states it returns recorded design decisions for games or design genes—what makers did, why, rejected options, and sources—and distinguishes itself from gamegene_search as a follow-up. The verb and resource are clear without opening the schema.

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?

States the use case (give sourced precedents, usually after gamegene_search), instructs batching up to 30 slugs instead of one-by-one calls, and recommends format=cite for answering design questions. It lacks explicit when-not-to-use guidance, but the alternatives and conditions are strong.

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