EcoGameWiki

wiki_aggregate

Compute an aggregate over the wiki's entities — count / sum / avg / min / max of a numeric field across a whole kind, with an optional numeric 'where' filter. Use for 'how many…', 'what's the average/total/highest…' questions. 'count' needs no field (counts entities, or those matching 'where'); sum/avg/min/max require a 'field'. Supports the same optional 'category' scope as wiki_rank (food/item/species). Kinds and field names are the SAME as wiki_rank — see that tool's per-kind field lists. Example: { kind: "recipe", metric: "count", where: { field: "skill_level", op: ">", value: 5 } } → how many recipes need skill level above 5. Scoped: { kind: "food", metric: "avg", field: "calories", category: "vegetable" } → average calories of vegetables. Optional character/server PROFILE (skill_level/skills, talents, modules/module, server) recomputes the same profile-sensitive metrics as wiki_rank (recipe labor/craft_minutes; tool damage/calories_burn/durability_burn; item harvest_yield/power_watts; species yield_total/yield_min_total); static fields ignore it (the result carries a note). No profile = base aggregate.

Input Schema

TableJSON Schema

Name	Required	Description
`kind`	Yes	Which entity set to aggregate over.
`field`	No	Numeric field for sum/avg/min/max (required for those). Optional for count — with a field, count includes only entities that have it.
`where`	No	Optional single numeric filter applied before ranking/aggregating, e.g. { field: "weight", op: "<", value: 1000 }. The field must come from the same per-kind set as 'by'/'field'.
`metric`	Yes	Which aggregate to compute.
`module`	No	A single module name/type, or a comma-separated list (alternative to modules[]).
`server`	No	Model a DIFFERENT server's difficulty (default = this server's real settings; omit for accurate answers). Fields: craftResource, craftTime, growth, garbageRatio, fuelEfficiency, foodVariety, foodTastiness, baseGain, minBalanced, maxBalanced. Only craft_minutes is server-sensitive for ranking.
`skills`	No	Per-skill levels: { "<skill FullName>": level }. Overrides skill_level for those skills.
`modules`	No	Upgrade-module names/types installed (multiple slots stack).
`talents`	No	Talent names/types to treat as learned (profile-sensitive metrics only).
`category`	No	Optional: scope to ONE tag/category before ranking/aggregating, e.g. "seed", "vegetable", "gun". Only the tagged kinds (food / item / species) support this. Use the category's name from a wiki_search result; matching is case- and plural-insensitive.
`skill_level`	No	A single skill level applied to every governing skill (profile-sensitive metrics only).

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure and acquits itself well. It explains count's dual behavior (counts entities or those matching 'where'; with a field, counts only entities that have it), profile-sensitive metrics versus static fields, the note on static-field results, the meaning of omitted profile (base aggregate), and the server sensitivity note—far beyond typical descriptions.

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?

The description is front-loaded with a clear purpose statement, followed by usage guidance, parameter semantics, and examples. It is long but each sentence contributes necessary detail for a complex tool with profile sensitivity and multiple metrics. Minor redundancy in repeating 'profile-sensitive metrics' could be trimmed, but overall it is well-structured and not wasteful.

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?

The description covers a large parameter space (11 params), nested objects, profile sensitivity, category scoping, and cross-references. However, there is no output schema and the description does not explicitly state the exact return structure (e.g., a plain number vs. object with note). The examples imply the returned aggregate value, and static-field note behavior is mentioned, but a slightly more explicit return-format statement would make it fully complete.

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?

Schema description coverage is 100%, so the baseline is 3. The description adds substantial clarity beyond the schema: it explains that count requires no field and what the field means for count, that sum/avg/min/max require a field, and that kinds/field names are identical to wiki_rank (saving the agent from re-learning field lists). The worked examples further clarify parameter combination semantics.

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 'Compute an aggregate over the wiki's entities' and enumerates the metrics (count/sum/avg/min/max) plus the resource (entities of a kind). It immediately differentiates from sibling wiki_rank by focusing on aggregates and references the same field lists, making the tool's role unambiguous.

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

Usage Guidelines4/5

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

The description explicitly states 'Use for "how many…", "what's the average/total/highest…" questions' and provides concrete examples for both unfiltered and category-scoped usage. It does not explicitly state 'do not use for ranked lists' but the strong cross-reference to wiki_rank ('Kinds and field names are the SAME as wiki_rank') implies that ranking is handled elsewhere.

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

All EcoGameWiki tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation2/5

search and wiki_search both perform full-text search over the Eco wiki and return similar ranked matches, making them easy to confuse. fetch and wiki_get also overlap as page-retrieval tools, though the crafting calculators are clearly differentiated.

Naming Consistency3/5

Most tools use a wiki_ prefix, but fetch and search break that pattern, and the suffixes are stylistically mixed (wiki_bom, wiki_calc, wiki_total_raw, wiki_contract_basics). The names remain readable and consistently lowercase snake_case, so the inconsistency is moderate rather than chaotic.

Tool Count4/5

Ten tools is a reasonable size for a wiki server covering search, retrieval, structured facts, numeric analysis, and crafting calculations. The count is slightly padded by the duplicate search tools and overlapping retrieval tools, but it is not excessive.

Completeness5/5

The tool set covers browsing, full-text search, structured entity facts, ranking, aggregation, multiple crafting-depth views, and gameplay mechanics like contracts. There are no obvious read-side dead ends, and write operations are appropriately absent for a wiki reference server.

Resources

Need Help?