get_recipes / price_recipe: filters narrow `recipes` but ship the full unfiltered graph index anyway (MCP-unusable) #254

New issue

Closed

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

coilyco-ops commented

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

Member

Summary

get_recipes and price_recipe apply their filters correctly to the recipes array, but emit tags, byProduct, byStation, and bySkill completely unfiltered on every call. The result blows the MCP client response cap even on a single-recipe query, so neither tool is usable over MCP for its primary documented use case.

get_recipes' own description says "Summary-first — the full graph is ~1,450 recipes, so pass a filter or raise limit." Passing a filter does not help, because the filter never reaches the index maps.

Evidence

mcp__eco__get_recipes(product="SteelAxeItem") → 196,560 characters, over the cap.

Byte breakdown of that response:

key	bytes	filtered?
`tags`	72,444	no
`byProduct`	60,070	no (1,323 keys)
`byStation`	29,272	no
`bySkill`	27,253	no (34 keys)
`skills`	6,462	no
`recipes`	659	yes — 1 recipe, correct

counts.recipes: 1, recipesMatched: 1, recipesReturned: 1. The caller asked for one recipe, got the right one recipe, and 189 KB of graph index around it. Signal is 0.34% of payload.

price_recipe(product="SteelAxeItem") → 197,311 characters, identical shape. Its actual output (recipes[0].cost, 1,401 bytes) is 0.7% of the response.

Worth stressing: the pricing logic itself is good. SteelAxeItem costed cleanly at perUnitCost: 22.48, complete: true, unpricedInputs: [], with each leaf correctly attributed source: "market" vs source: "craft". Only the envelope is broken.

Expected

When a filter (product / skill / station) or a limit is supplied, the index maps should be restricted to the returned recipes — or omitted entirely, since a caller who filtered to one recipe has no use for a 1,323-key product index.

price_recipe in particular should probably not return the recipe-graph schema at all; it has one documented job (cost one product) and should return that.

Repro

mcp__eco__get_recipes(product="SteelAxeItem")
mcp__eco__get_recipes(skill="SmeltingSkill", limit=2)
mcp__eco__price_recipe(product="SteelAxeItem")

All three exceed the response cap. Found during a QA sweep of all 25 Eco MCP tools.

## Summary `get_recipes` and `price_recipe` apply their filters correctly to the `recipes` array, but emit `tags`, `byProduct`, `byStation`, and `bySkill` **completely unfiltered** on every call. The result blows the MCP client response cap even on a single-recipe query, so neither tool is usable over MCP for its primary documented use case. `get_recipes`' own description says "Summary-first — the full graph is ~1,450 recipes, so pass a filter or raise `limit`." Passing a filter does not help, because the filter never reaches the index maps. ## Evidence `mcp__eco__get_recipes(product="SteelAxeItem")` → **196,560 characters**, over the cap. Byte breakdown of that response: | key | bytes | filtered? | |---|---:|---| | `tags` | 72,444 | no | | `byProduct` | 60,070 | no (1,323 keys) | | `byStation` | 29,272 | no | | `bySkill` | 27,253 | no (34 keys) | | `skills` | 6,462 | no | | **`recipes`** | **659** | **yes — 1 recipe, correct** | `counts.recipes: 1`, `recipesMatched: 1`, `recipesReturned: 1`. The caller asked for one recipe, got the right one recipe, and 189 KB of graph index around it. **Signal is 0.34% of payload.** `price_recipe(product="SteelAxeItem")` → **197,311 characters**, identical shape. Its actual output (`recipes[0].cost`, 1,401 bytes) is **0.7%** of the response. Worth stressing: the pricing logic itself is good. `SteelAxeItem` costed cleanly at `perUnitCost: 22.48`, `complete: true`, `unpricedInputs: []`, with each leaf correctly attributed `source: "market"` vs `source: "craft"`. Only the envelope is broken. ## Expected When a filter (`product` / `skill` / `station`) or a `limit` is supplied, the index maps should be restricted to the returned recipes — or omitted entirely, since a caller who filtered to one recipe has no use for a 1,323-key product index. `price_recipe` in particular should probably not return the recipe-graph schema at all; it has one documented job (cost one product) and should return that. ## Repro ``` mcp__eco__get_recipes(product="SteelAxeItem") mcp__eco__get_recipes(skill="SmeltingSkill", limit=2) mcp__eco__price_recipe(product="SteelAxeItem") ``` All three exceed the response cap. Found during a QA sweep of all 25 Eco MCP tools.

coilyco-ops referenced this issue

2026-08-13 17:07:48 +00:00

Six tools exceed the MCP response cap on a default no-argument call, with no parameter available to bound the payload #256

coilyco-ops referenced this issue from a commit

2026-08-13 17:34:33 +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:33 +00:00