AI Decision System
Replayable, offline-verifiable records for AI-assisted go/no-go decisions: experiment promotions, typed model answers and human-approved actions.
개인 계정의 공개 저장소 소유자는 GitHub로 로그인해 운영자를 확인하고 소개를 직접 관리할 수 있습니다. 관리자 승인은 필요하지 않습니다.
로그인한 뒤 확인 파일을 만들어 이 저장소의 기본 브랜치에 30분 안에 커밋해 주세요. 다른 브랜치나 포크의 파일은 인정하지 않습니다. 파일을 올린 뒤 아래에서 확인하면 관리자 승인 없이 관리할 수 있습니다. 자격을 유지하려면 파일을 남겨 두세요.
로그인이 필요하면 로그인 화면으로 이동합니다. 로그인 후 이곳으로 돌아와 원하는 확인 버튼을 다시 눌러 주세요.
프로젝트 폴더에서 /nomorevibe verify를 실행하면 소유권을 확인하고 소개를 직접 관리할 수 있습니다.
1분 만에 확인하기MCP server to drive Dragon Age: Origins
저장소 README에서 가져옴
README 전체를 불러오는 중입니다.
README 전문 보기 ↗A test bench inside Dragon Age: Origins for AI agents and scripts: a DAOLib plugin that serves the running game over MCP and plain HTTP on 127.0.0.1. Inspired by Skyrim's devbench.
An agent asks the game what it wants to know (the creatures around, their health and effects, the quests, what the interface has up) and gives it orders by id, then waits for the event it expects instead of sleeping and reading logs. It can stage a test's case, walk the party across the world, loot, level up, talk, and play a whole campaign with no screen at all. Other DAOLib plugins add tools and events of their own through a small C interface, src/api/EluvianAPI.h (MIT).
It is tested on the GOG build of the game, version 1.05.13263.0 (DAOLib's address library maps EA's and Steam's too), and answers on 127.0.0.1 only with no authentication: a development bench, not something to ship to players.
whocares66-dev.github.io/DAOEluvianMCP: every tool with its arguments, the events, and the C interface, generated from the code (python tools/build_docs.py --serve builds it locally).
Eluvian is a DAOLib plugin, so the game has DAOLib first: its zip, extracted into the game's install folder, the one that holds bin_ship. An Eluvian release is extracted the same way, into the same folder, with the game closed. All of it lands in one folder, bin_ship\daolib\plugins\eluvian\: eluvian.dll, eluvian.pdb (which lets a crash log name Eluvian's own code), the bridge eluvian_bridge.py, and VERSION.txt, which names the DAOLib release it was built on, the oldest it works with. Deleting that folder takes Eluvian out. CHANGELOG.md says what each release brought.
Start the game as always. Documents\BioWare\Dragon Age\daolib\loader.log then says that eluvian was loaded, and eluvian.log beside it has the port Eluvian serves on and every tool call with its arguments and answer.
An agent connects through the bridge, eluvian_bridge.py, a stdio MCP server that outlives the game and needs only Python 3. It forwards to the game while it runs, and adds game_launch, game_new, game_quit, game_status, game_saves and game_instance. Started from the game's folder it takes that game as its own:
claude mcp add eluvian -- python "C:\Program Files (x86)\GOG Galaxy\Games\Dragon Age Origins\bin_ship\daolib\plugins\eluvian\eluvian_bridge.py"
In a clone of this repository the same file is tools\eluvian_bridge.py, which .mcp.json starts; there it takes the GOG install's game unless --exe names another.
The game runs one at a time, except as a named instance: a second copy beside the first with its own saves, settings, logs and port, which a loader of DAOLib later than 0.1.0 makes of a copy started with a name. A bridge drives one copy; game_instance {"name": "mytest"} makes it that instance's, and --instance mytest starts it so; any other tool's "instance": "mytest" is that copy's for that call only. dev/PLAYBOOK.md has the calls.
A script calls one tool from the shell and reads the answer as JSON (here from a clone):
python tools\eluvian_bridge.py --call game_launch '{"owner":"me","load":{"character":"Lyna","kind":"manual","number":1}}'
python tools\eluvian_bridge.py --call creatures '{"side":"hostile"}'
Or straight to the running game, on port 8930 or the next free one (eluvian.json beside the logs says which):
curl http://127.0.0.1:8930/api/health
curl -X POST http://127.0.0.1:8930/api/tool/creatures -d '{"side":"hostile"}'
This repository also builds a second MCP server, ghilana.exe. It reads the game's archives, data tables, talk tables, templates and textures straight from disk, so the game doesn't need to be running. It's a 64-bit program that your MCP client starts, and it finds the install and your Documents folder on its own:
claude mcp add ghilana -- "C:\path\to\ghilana.exe"
claude mcp add ghilana -- "C:\path\to\ghilana.exe" --game "E:\SteamLibrary\steamapps\common\Dragon Age Ultimate Edition"
Use --documents, --instance, --language and --cache to point it elsewhere, and --plugins for a game started with plugins from another folder (the bridge's game_launch plugins, a build's staged plugins), whose overrides the game then takes in place of bin_ship\daolib\plugins's. Use --campaign and --textures to say what the game is doing (the default is Origins at high texture quality), since that changes which copies of a file the game uses. ghilana.exe --call environment runs one tool from a shell, and --describe lists all of them. The tools are environment, resources, resource, conflicts, table, strings, query, references, extract and texture. When a file has several copies, Ghilana tells you which one the game uses, following the game's own load order. It never writes to the game's folders.
src/core: the bench without the game (HTTP, MCP, the tool registry, the event bus, and the tools that decide over other tools' answers), tested.src/game: the tools that read and drive the game, through DAOLib.src/plugin, src/api: the plugin itself, and the C interface other plugins include.src/ghilana: Ghilana's tools, built on DAOLib's core (extern/DAOLib/src/dao/core), which parses the game's file formats.tools/: building, deploying, packaging and releasing, the bridge, smoke.py (every tool once in the game) and build_docs.py (the docs site).docs/: the docs site's theme and the reference it is built from (_data/eluvian.json, what eluvian_describe prints).dev/: the docs above.Only to work on Eluvian: to use it, install a release. Visual Studio 2022 with the C++ workload, vcpkg with VCPKG_ROOT set, and Python 3. Everything that loads into the game is 32-bit, like the game itself. Ghilana is 64-bit.
git submodule update --init --recursive # DAOLib, and its address library
.\tools\build.ps1 -Preset debug -Test # the plugin, DAOLib's loader, the tests
.\tools\build.ps1 -Preset release -Test # what the game plays
.\tools\deploy.ps1 # the release build into the game (with the game closed)
.\tools\deploy.ps1 -Remove # take it out again
.\tools\package.ps1 # the release build as the zip a release carries
.\tools\build.ps1 -Preset ghilana -Test # ghilana.exe, 64-bit, and its tests (ghilana-release: what ships)
dev/RELEASING.md is how a release is cut.
CLAUDE.md has the project's rules: the one architectural rule, threads, the checks before a commit and before a merge, and how a change is seen in play.
GPLv3 (LICENSE), as DAOLib. src/api/EluvianAPI.h alone is MIT, so a plugin under any license can include it.