Skip to main content
Glama
ozcansayid

interactive-game-mcp

by ozcansayid
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Eğiteknoloji Etkileşimli İçerik Player Kabuğu & MCP Sunucusu

Bu proje; Eğiteknoloji kurumsal marka kimliği ve renk paletine tam uyumlu, 16:9 oranını koruyarak tüm cihazlarda (akıllı tahta, tablet, mobil, masaüstü) milimetrik olarak ölçeklenen, SCORM 1.2 uyumlu ve yapay zeka ajanlarının doğrudan içerik üretebilmesi için tasarlanmış bir Etkileşimli İçerik Player Kabuğu ve MCP (Model Context Protocol) Sunucusudur.

🎨 1. Tasarım & Mimari Standartları

Kurumsal Renk Paleti (Eğiteknoloji Standartları)

  • Ana Kurumsal (Primary): #052249 (Derin Okyanus Laciverti - Üst/alt çerçeve, kurumsal güven)

  • Ana Vurgu (Accent / CTA): #6cb22f (Zümrüt Yeşili - Doğru cevaplar, onay, başarı butonları)

  • Destekleyici Mavi: #086cd9 (İlerleme çubukları, kart seçimi, hiperlinkler)

  • Açık Buz Mavisi: #8fc3ff (Hover fonları, rozet zeminleri)

  • Açık Bölüm Fonu: #eaf4ff (İçerik kartı zeminleri, bilgi kutuları)

  • Nötr Tuval Zemin: #f8f8f9 (Temiz ve sade açık arka plan)

  • Yüksek Kontrastlı Metin: #080808

16:9 Otomatik Responsive Ölçekleme (Viewport Scaler)

  • Referans Çözünürlük: 1280 x 720 px.

  • #stage-container içerisindeki #app-viewport, ekran en-boy oranına göre transform: scale(...) ile bozulmadan, taşmadan ve bulanıklaşmadan ortalanır (letterbox / pillarbox).

Modüler ve Opsiyonel UI Kontrolleri (features)

Her içerikte tüm butonların olması zorunlu değildir. İhtiyaca göre konfigürasyondan true/false olarak yönetilir:

features: {
  audio: true,          // Ses açma/kapatma butonu & efektler
  navigation: true,     // İleri / Geri butonları
  playButton: false,    // Başlangıç kapak ekranı ve "Başla" butonu
  score: true,          // Skor / Puan rozeti
  timer: true,          // Süre sayacı
  lives: true,          // Can sistemi (❤️❤️❤️)
  fullscreen: true,     // Tam ekran butonu
  progressBar: true     // İlerleme çubuğu
},
initialLives: 3,        // Başlangıç can sayısı (1-5)
timerMode: "stopwatch", // "stopwatch" (kronometre) veya "countdown" (geri sayım)
timerDuration: 60       // Geri sayım saniyesi

🧠 Arka Plan Durum (State) & Telemetri API'si

Geliştiriciler veya AI ajanları içerik içinde doğrudan şu metodları çağırabilir:

  • shell.addScore(points): Puan ekler.

  • shell.subtractScore(points): Puan düşürür.

  • shell.loseLife(1): Bir can eksiltir. Canlar tükenince otomatik başarısızlık modalı açılır.

  • shell.gainLife(1): Ekstra can verir.

  • shell.startTimer("stopwatch" | "countdown", duration): Süreyi başlatır. Geri sayımda süre bitince "Süre Doldu" ekranı açılır.

  • shell.getTelemetryData(): { score, elapsedSeconds, formattedTime, livesRemaining, isCompleted } nesnesini döndürür. SCORM veya harici LMS raporlama için hazırdır.

Dahili Ses Sentezleyici (Procedural Web Audio API)

Harici .mp3 dosyalarına ihtiyaç duymadan, tarayıcının yerel Web Audio API'si ile doğru, yanlış, buton tıklama ve bölüm sonu zafer fanfarı çalar.

SCORM 1.2 Desteği

  • imsmanifest.xml paketi hazırdır.

  • core/scorm-api.js aracılığıyla LMS mevcutsa cmi.core.score.raw, cmi.core.lesson_status verilerini otomatik iletir; LMS yoksa bağımsız (mock) modda sessizce çalışmaya devam eder.

Related MCP server: antics-mcp

🚀 2. MCP (Model Context Protocol) Kurulumu ve Entegrasyonu

Bu MCP sunucusu; Antigravity IDE, Claude Desktop, Cursor veya herhangi bir MCP istemcisine bağlanabilir.

mcp_config.json veya claude_desktop_config.json Tanımı:

{
  "mcpServers": {
    "egiteknoloji-interactive": {
      "command": "node",
      "args": [
        "d:\\wamp64\\www\\mcp\\etkilesimli-icerik\\mcp-server\\server.js"
      ]
    }
  }
}

🛠️ 3. MCP Sunucusunun Sunduğu Yetenekler (Tools)

Tool Adı

Açıklama

get_framework_specs

16:9 boyut kurallarını, Eğiteknoloji renk kodlarını, SCORM ve ses API'sini döndürür.

list_activity_templates

Desteklenen etkinlik türlerini (matching, quiz) ve beklenen JSON veri şemalarını listeler.

scaffold_interactive_activity

Yapay zeka ajanının ürettiği sorular/kavramlar ile sıfırdan çalışan, paketlenmiş 16:9 SCORM projesi oluşturur.

💡 4. Yapay Zeka Ajanına Verilebilecek Örnek İstemler

MCP bağlandıktan sonra ajana şu şekilde komut verebilirsiniz:

"Bana 4. sınıf Fen Bilgisi 'Besinlerimiz ve Görevleri' konusu için 4 çiftli bir Eğiteknoloji eşleştirme oyunu hazırla. Ses olsun, süre sayacı olmasın, skor aktif olsun."

Ajan arka planda:

  1. get_framework_specs ile renk ve kuralları inceler.

  2. scaffold_interactive_activity tool'unu çağırarak içeriği tek seferde üretir.

  3. Çıktı olarak WAMP veya yerel klasörde doğrudan LMS'e yüklenebilecek SCORM hazır bir paket teslim eder.

📂 5. Klasör Hiyerarşisi

etkilesimli-icerik/
├── index.html                  # Canlı demo & etkinlik değiştirici (Eşleştirme + Quiz)
├── imsmanifest.xml             # SCORM 1.2 manifest dosyası
├── logo_colorful_with_white_text.png
├── logo_icon_colorful.png
├── core/
│   ├── shell.css               # Eğiteknoloji tasarım sistemi & 16:9 ölçekleyici stilleri
│   ├── shell.js                # Shell yönetimi, timer, skor, navigasyon, responsive ölçekleyici
│   ├── audio-synth.js          # Dahili Web Audio API ses motoru
│   └── scorm-api.js            # SCORM 1.2 LMS wrapper & mock
├── activities/
│   ├── matching/               # 1. Örnek: Tıkla-Eşleştir (Click to Pair) Oyunu
│   │   ├── matching.css
│   │   └── matching.js
│   └── quiz/                   # 2. Örnek: Çoktan Seçmeli Test Motoru
│       ├── quiz.css
│       └── quiz.js
└── mcp-server/                 # MCP Sunucusu (Antigravity & AI Ajan Entegrasyonu)
    ├── package.json
    └── server.js

🖥️ 6. Canlı Önizleme

Tarayıcınızda doğrudan d:\wamp64\www\mcp\etkilesimli-icerik\index.html dosyasını açabilir veya WAMP sunucunuz aktifse http://localhost/mcp/etkilesimli-icerik/ adresinden test edebilirsiniz.

Available Tools

3 tools
get_framework_specsA

Eğiteknoloji 16:9 responsive arayüz standartlarını, kurumsal renk paletini, SCORM 1.2 kurallarını ve opsiyonel shell bayraklarını (ses, puan, butonlar vb.) getirir.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the burden of behavioral disclosure. It conveys a read-only retrieval operation and lists the returned content categories, but it does not describe the output format, error conditions, or any domain-specific caveats such as SCORM version implications.

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?

A single compact sentence enumerates all the spec categories without filler or repetition. The key object ('framework specs') and its components are front-loaded, making it easy for an agent to parse.

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?

For a zero-parameter, no-output-schema retrieval tool, the description provides enough content detail for an agent to know what to expect. It could be stronger by stating the response shape or noting that this spec should be fetched before scaffolding, but nothing essential to invoking it correctly is 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?

The tool takes zero parameters, and the input schema is an empty object, so schema coverage is trivially complete. The description adds value by indicating what the retrieved spec contains, which is above the baseline needed for a parameterless tool.

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 names a specific retrieval action ('getirir') and a concrete resource: Eğiteknoloji 16:9 interface standards, brand palette, SCORM 1.2 rules, and optional shell flags. This clearly identifies what the tool does, though it does not explicitly contrast itself with sibling tools like list_activity_templates or scaffold_interactive_activity.

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

Usage Guidelines2/5

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

There is no statement about when to call this tool, when not to call it, or how it relates to alternatives such as scaffolding an activity. The only guidance is implicit in the name and description, so an agent has to infer the appropriate moment to invoke it.

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

list_activity_templatesB

Hazır etkileşimli içerik şablonlarını (Eşleştirme, Çoktan Seçmeli Test vb.) ve veri yapılarını listeler.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.2/5.0
Behavior2/5

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

There are no annotations, so the description carries full behavioral burden. The verb 'lista' implies a read-only operation, but the description does not disclose return format, whether data structures are nested, pagination, or any side-effect traits. It is minimally transparent but lacks the richness expected for a tool with no annotation support.

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?

One focused sentence that starts with the action, names the resource, and gives two concrete examples. No filler or redundancy, and the structure is easy to parse.

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?

For a zero-parameter listing tool, the description covers the basic purpose well. However, with no output schema and no usage guidance or return-value details, it leaves the agent unsure about what the returned data structures look like or how to interpret the output. Adequate but with clear gaps for an agent attempting to invoke it effectively.

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 tool has zero parameters, so the baseline is 4. The description adds meaningful context by clarifying that it lists templates along with their data structures, even though there are no parameters to explain. Nothing more is needed.

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 states a specific verb ('listeler' – lists) and a clear resource: ready interactive content templates and data structures, with concrete examples (Matching, Multiple Choice Quiz). It is immediately distinguishable from siblings like scaffold_interactive_activity, though it does not explicitly name the sibling or contrast with get_framework_specs.

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

Usage Guidelines2/5

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

No guidance is given about when to use this tool versus the siblings. It implies 'use when you need to see available templates,' but there are no explicit usage contexts, prerequisites, or exclusions. With two sibling tools present, this is a notable gap.

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

scaffold_interactive_activityA

Belirtilen konfigürasyon ve veri setiyle (Quiz veya Eşleştirme) 16:9 oranlı, SCORM 1.2 uyumlu, Eğiteknoloji tasarımlı yeni bir etkileşimli içerik projesi oluşturur.

ParametersJSON Schema
NameRequiredDescriptionDefault
dataYesEtkinliğe özgü soru veya eşleştirme veri seti.
titleYesEtkinlik başlığı (ör. 'Güneş Sistemi Gezegenleri').
featuresNoOpsiyonel UI bileşenleri bayrakları.
activityTypeYesEtkinlik türü: 'matching' (Eşleştirme) veya 'quiz' (Çoktan Seçmeli).
outputDirectoryYesProjenin oluşturulacağı mutlak veya göreceli klasör yolu.

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are present, so the description carries the full burden. It does disclose a creation behavior and output constraints (SCORM 1.2, 16:9, brand design), but it does not state whether existing output directories are overwritten, what files are produced, or how the result is returned.

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 a single dense sentence that leads with the action and contains no filler. Each qualifier adds meaningful information about the generated project.

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

Completeness2/5

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

With no output schema, no annotations, and a vague nested data parameter, the description is not complete enough for an agent to form a full mental model. The expected shape of 'data' is unspecified, file-system/overwrite behavior is absent, and the relationship to get_framework_specs and list_activity_templates is not explained.

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 the baseline applies. The description only restates the high-level configuration/data and Quiz/Matching distinction; it adds no detail about the shape of the data object or the feature flags beyond what the schema already describes.

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 opens with a specific verb-resource pair ('yeni bir etkileşimli içerik projesi oluşturur') and adds concrete scope: Quiz/Matching, 16:9, SCORM 1.2, and Eğiteknoloji design. This clearly distinguishes it from the informational siblings get_framework_specs and list_activity_templates.

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

Usage Guidelines3/5

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

The description implies the tool is for generating an activity project from configuration and data, but it never explicitly says when to prefer it over alternatives or mentions exclusions. It also does not indicate whether the user should first consult framework specs or activity templates.

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.

  1. 3 tool updatesv1.0.0
    • First observedget_framework_specs
    • First observedlist_activity_templates
    • First observedscaffold_interactive_activity
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.8/5.0

Scored across 3 tools

Disambiguation5/5

Each tool targets a distinct responsibility: fetching framework specs, listing available templates, and scaffolding a new activity. There is no meaningful overlap between them.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern: get_, list_, scaffold_. The verbs clearly indicate the action and the nouns identify the resource.

Tool Count5/5

Three tools is a focused, well-scoped set for a scaffolding-oriented MCP server. Each tool earns its place and none feels redundant.

Completeness5/5

The tool surface fully covers the core workflow: retrieve standards, inspect available templates, and generate a new interactive activity. There are no obvious dead ends for the server's stated purpose.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers