get_skills / get_recipes serve the vanilla AutoGen graph with no way to reach the modded server's real skills #263

New issue

Closed

opened 2026-08-13 17:09:31 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-13 17:09:31 +00:00

Member

Summary

get_skills describes itself as "the profession axis behind 'what is this specialty actually worth'." It returns the 44 vanilla skills from the AutoGen seed and has no server parameter, so on a modded server it silently omits the specialties players actually hold.

Evidence

mcp__eco__get_skills() returns serverSpecific: false, sourceKind: "autogen", 44 skills, recipesCovered: 1411.

mcp__eco__get_progression(citizen="Kirdec") against the default server returns bySpecialty containing skills that appear nowhere in get_skills:

skill in use	citizens holding it	in `get_skills`?
`FishingReloadedSkill`	7	no
`AnimalHusbandrySkill`	6	no
`LibrarianSkill`	5	no
`BiochemistSkill`	2	no
`MixologySkill`	2	no
`BeekeepingSkill`	1	no

The default server advertises itself as "highly modded ... 20+ [mods] including Biochemist, Animal Husbandry, Greenhouses, BunWulf Agricultural, Librarian, BunWulf HardwareCo" in its own /info description, so this is the expected server, not an edge case. get_progression even reports firstSpecialtyGains for LibrarianSkill on day 0 — a modded skill was among the first five specialties taken on the server.

The same applies to get_recipes, which also reports serverSpecific: false / sourceKind: "autogen".

Mitigating

Both tools do disclose this via the serverSpecific flag, and get_recipes' description explicitly promises "The payload names its source and whether it is the running server's modded graph or the vanilla seed." So this is disclosed, not hidden — which is why I am filing it as a gap rather than a correctness bug.

But get_skills has no server parameter at all, so there is no path to the modded axis even for a caller who reads serverSpecific: false and wants better. And a warnings entry along the lines of "this is the vanilla seed; the target server runs mods whose skills are not represented here" would make the limitation legible without the caller having to cross-reference get_progression.

Expected

A server parameter on get_skills, resolving to the running server's modded graph where available.
Failing that, a warning when the payload is the vanilla seed, so the omission is stated rather than inferred.

Repro

mcp__eco__get_skills()                          # 44 vanilla skills, no Biochemist/Librarian
mcp__eco__get_progression(citizen="Kirdec")     # bySpecialty includes both

Found during a QA sweep of all 25 Eco MCP tools.

## Summary `get_skills` describes itself as "the profession axis behind 'what is this specialty actually worth'." It returns the 44 vanilla skills from the AutoGen seed and has no `server` parameter, so on a modded server it silently omits the specialties players actually hold. ## Evidence `mcp__eco__get_skills()` returns `serverSpecific: false`, `sourceKind: "autogen"`, 44 skills, `recipesCovered: 1411`. `mcp__eco__get_progression(citizen="Kirdec")` against the default server returns `bySpecialty` containing skills that appear nowhere in `get_skills`: | skill in use | citizens holding it | in `get_skills`? | |---|---:|---| | `FishingReloadedSkill` | 7 | no | | `AnimalHusbandrySkill` | 6 | no | | `LibrarianSkill` | 5 | no | | `BiochemistSkill` | 2 | no | | `MixologySkill` | 2 | no | | `BeekeepingSkill` | 1 | no | The default server advertises itself as "highly modded ... 20+ [mods] including Biochemist, Animal Husbandry, Greenhouses, BunWulf Agricultural, Librarian, BunWulf HardwareCo" in its own `/info` description, so this is the expected server, not an edge case. `get_progression` even reports `firstSpecialtyGains` for `LibrarianSkill` on day 0 — a modded skill was among the first five specialties taken on the server. The same applies to `get_recipes`, which also reports `serverSpecific: false` / `sourceKind: "autogen"`. ## Mitigating Both tools *do* disclose this via the `serverSpecific` flag, and `get_recipes`' description explicitly promises "The payload names its source and whether it is the running server's modded graph or the vanilla seed." So this is disclosed, not hidden — which is why I am filing it as a gap rather than a correctness bug. But `get_skills` has no `server` parameter at all, so there is no path to the modded axis even for a caller who reads `serverSpecific: false` and wants better. And a `warnings` entry along the lines of "this is the vanilla seed; the target server runs mods whose skills are not represented here" would make the limitation legible without the caller having to cross-reference `get_progression`. ## Expected - A `server` parameter on `get_skills`, resolving to the running server's modded graph where available. - Failing that, a warning when the payload is the vanilla seed, so the omission is stated rather than inferred. ## Repro ``` mcp__eco__get_skills() # 44 vanilla skills, no Biochemist/Librarian mcp__eco__get_progression(citizen="Kirdec") # bySpecialty includes both ``` Found during a QA sweep of all 25 Eco MCP tools.

coilyco-ops referenced this issue from a commit

2026-08-13 17:34:34 +00:00

fix(recipes): stop wrapping a one-recipe answer in the whole graph index

coilyco-ops closed this issue

2026-08-13 17:34:34 +00:00