EcoCarbonWiki

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

With no annotations, the description carries the full burden. It discloses that the output is Markdown and gives valid path examples, but does not explicitly state that this is a read-only operation or describe error handling. Lacks deeper behavioral context, though the fetch action is inherently read-only.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the action and resource, with examples appended for clarity. Every word earns its place with zero redundancy.

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

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

Given the tool's simplicity (one parameter, no output schema), the description covers purpose, output format, and path formats sufficiently. It does not mention edge cases like non-existent pages, but for a basic fetch this is a minor gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already documents the 'path' parameter with an example. The description adds value by broadening the example set ('/wiki', '/wiki/item/iron-bar', '/wiki/recipes'), indicating that index pages are also valid. This goes beyond the schema's single example.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'fetch' and identifies the resource 'single Eco wiki page' with output format 'Markdown'. The word 'single' implicitly differentiates it from aggregate siblings like wiki_aggregate or wiki_total_raw.

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

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

Provides clear context for fetching a single page and implies when to use it, but does not explicitly mention alternatives or exclusion criteria. Siblings like wiki_get and search are not referenced, leaving usage boundaries to inference.

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

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

With no annotations, the description carries the burden for behavioral disclosure. It explains the output structure (ranked matches with name, kind, URL, snippet) but does not mention read-only status, rate limits, or error behavior, though the search semantics imply non-mutation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that front-loads the action, includes specific content coverage, and describes the return payload without unnecessary words.

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

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

For a read-only search tool, the description is largely complete: it states what is searched, what is returned, and the schema covers parameters. With no output schema, the description's mention of return fields is valuable, but it lacks guidance on edge cases or relationship to sibling search tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and both parameters (query, limit) are well-described in the schema. The description adds context about search scope but no additional parameter-level semantics, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs full-text search on the Eco game wiki, lists content categories, and describes the return format. However, it does not differentiate itself from the sibling tool 'wiki_search', so it lacks sibling distinction.

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

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

The description implies the tool is used for searching the wiki but provides no explicit guidance on when to use it versus alternatives like 'fetch' or 'wiki_search', and no exclusions or alternative recommendations.

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

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.

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.

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.

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.

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.

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.

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

With no annotations, the description carries full behavioral burden. It discloses key traits: transitive summation across the whole tree, primary-recipe selection with alternatives listed, optional ingredient filtering returning total+role, and server override behavior. It does not mention error handling or return format, but the disclosed behavior is substantial and non-contradictory.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a dense but well-structured paragraph: definition first, then usage context, sibling distinctions, parameter walkthrough, and a concrete example. It is slightly long but every sentence adds value; the front-loading of the core purpose and differentiators makes it easy to scan.

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

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

For a 10-parameter tool with nested objects and no output schema, the description is quite complete: it explains all parameter categories, gives an example, and covers the main use cases. The lack of an explicit return-shape description is a minor gap, but the example and behavioral details largely compensate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond schema: it clarifies slug as target item or recipe, quantity as units of target with default/clamp, ingredient as specific component with role determination, and recipe_slug as override with alternatives. The example ties parameters together, enriching the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific definition: 'Bill-of-materials for making a target item/recipe: the full crafting tree INCLUDING the crafted intermediate sub-components (NOT just raw leaves).' It names the exact resource (crafting tree) and verb (compute BOM), and explicitly distinguishes from siblings wiki_total_raw and wiki_calc, eliminating ambiguity.

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

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

It states precisely when to use: 'This is the tool for "how many <component> does it take to make <target>"' and gives exclusions: 'Differs from wiki_total_raw (raw materials only) and wiki_calc (exact one-step numbers for a single recipe).' It also explains how to pass item vs recipe slug and optional overrides, providing clear usage context.

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

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

With no annotations, the description fully discloses behavior: it specifies exactly what is computed for each entity type (labor calories, craft time, XP, damage, yields), how parameters affect results, and that the response lists available modules/talents/skill with effect text. This goes well beyond a generic 'computes values' statement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but information-dense and well-structured by entity type. The opening sentence front-loads the core purpose, and every subsequent clause adds specific calculation behavior without fluff, earning its place.

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

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

The tool is complex (9 params, nested server object, no output schema), yet the description covers all entity types, parameter scoping, server-override semantics, and even hints at response content by saying it lists available modules/talents/skill. This is complete enough for an agent to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds significant meaning by mapping parameters to entity types (e.g., skill_level for recipes/tools/mining, housing/variety/balanced/tastiness for food). It also explains that omitted levers use base values and that the response helps the user pick valid options, which aids correct parameter selection.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Compute EXACT numbers for a chosen setup' and then enumerates specific outputs for recipes, food, tools, mineable blocks, and species. This clear verb+resource scope distinguishes it from sibling fetch/search/aggregate tools, which focus on retrieval rather than calculation.

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

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

The description provides clear operational context per entity type (e.g., 'Omit a lever to leave it at base' and 'Omit for accurate answers' regarding server override). However, it never explicitly names sibling alternatives or states when not to use this tool, so it lacks the full 'when/when-not' guidance needed for a 5.

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

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

With no annotations provided, the description carries the full burden. It transparently outlines the tool's scope (kinds, rewards/escrow, completion verification) and its read-only explanatory nature via the verb 'explain.' It does not delve into return format or limitations, but for a simple knowledge tool this is sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core purpose and followed by a usage hint. Every word earns its place, and there is no fluff or redundancy.

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

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 tool, the description fully covers what the tool does and when to use it. It specifies the topic (Solomon's help contracts/quests), the subtopics (kinds, rewards/escrow, verification), and the trigger question type. There is no missing context that would confuse an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the input schema is empty and schema coverage is 100%. The baseline for 0-param tools is 4, and the description correctly implies that no arguments are needed. No additional parameter semantics are required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Explain') and clearly identifies the resource ('Solomon's help contracts and quests') and the aspects covered (kinds, rewards/escrow, completion verification). This distinguishes it from sibling wiki tools that are generic fetch or search operations, making the purpose immediately clear.

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

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

The phrase 'Use for "how do contracts/quests work" questions' provides explicit context for when to select this tool. It does not explicitly mention when not to use it or name alternatives, but the guidance is clear enough for an agent to make a correct choice.

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

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

With no annotations provided, the description fully discloses behavior: it is a read operation, it can return multiple pages, and ambiguous slugs return all matches. It also details what facts are included for each kind, even warning that placed-object measurements are included so the agent does not assume they are missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every sentence earns its place given the domain complexity. The core purpose and batching advice are front-loaded, followed by a structured breakdown of kinds and a clear fallback instruction for omitting 'kind'.

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

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

With no output schema, the description provides a comprehensive account of what the tool returns and how to call it correctly. It covers all input combinations, explains edge cases, and gives enough domain-specific detail that an agent can select appropriate parameters without guessing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Though the schema already describes the parameters, the description greatly enriches their meaning. It explains each 'kind' value in detail (item, recipe, skill, category, species, biome), says the slug should come from wiki_search, and clarifies batching semantics and the fallback behavior for ambiguous slugs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Read full facts') and resource ('wiki pages'), and clearly defines the tool's scope: retrieving full page contents for one or many pages in a single call. It also distinguishes itself from related tools by explicitly naming wiki_calc and wiki_total_raw as alternatives for exact modified numbers and from-scratch chains.

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

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

The description gives explicit usage guidance: batch all needed pages, obtain slugs from wiki_search, and omit 'kind' only if unsure. It also specifies alternatives for recipe calculations (wiki_calc, wiki_total_raw), providing clear when-to-use and when-not-to-use context.

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

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

No annotations are provided, so the description carries the full disclosure burden, and it delivers thoroughly. It reveals that fields not applying to an entity simply exclude it, that bool fields read as 1/0, that optional profile inputs re-rank only profile-sensitive metrics while all others are static facts that yield a note, and that no profile gives base ranking. This is unusually complete behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Long, but every section earns its place given the tool's 12-parameter complexity. The purpose sentence is front-loaded, followed by structured bullet lists of per-kind fields, concrete examples with actual JSON, and a clearly delineated profile paragraph. Dense but well-organized and scannable.

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

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

With no output schema and 12 parameters including nested objects, the description must be nearly self-sufficient, and it is. It covers defaults, limits, kinds and their valid fields, boolean handling, the 'where' filter shape, category scoping, behavior when fields don't apply, and profile sensitivity — everything an agent needs to construct a correct call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already documents each parameter's type and purpose. The description nonetheless adds substantial value beyond the schema: the full per-kind field inventories, defaults (limit 5, max 25, order desc), boolean encoding for the 'where' filter, and the profile-sensitivity mapping. This meaningfully exceeds the baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Rank the wiki's entities by a NUMERIC field and return the top (or bottom) N.' It differentiates from the sibling search tool by explicitly instructing to use it for ranking questions and never guess-and-confirm with wiki_search. The purpose is unmistakable and distinct from siblings like wiki_aggregate.

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

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

Provides explicit when-to-use guidance: 'Use this for ANY "which has the most/least/highest/lowest X" question — never guess-and-confirm with wiki_search.' It names the primary alternative to avoid. It could enumerate other siblings (aggregate, calc, total_raw) but the single exclusion plus the clear trigger phrase is strong directional guidance.

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

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

With no annotations provided, the description carries the transparency burden. It discloses the return format (kind, name, slug, snippet) and the tool's role as a precursor to wiki_get_*, which is useful behavior. It does not mention rate limits or edge cases, but for a read-only search tool this is sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the main purpose in the first sentence, and provides only essential instructions in the second. No filler.

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

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

The description fully covers the tool's purpose, scope, return payload, and relationship to sibling tools. Given the simple parameter set and lack of output schema, it is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides complete descriptions for both parameters (query and limit), so the baseline is 3. The description adds no additional parameter semantics beyond what the schema offers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Full-text search') and the resource ('the Eco game wiki') along with the content types covered. It distinguishes itself from sibling wiki_get by explicitly directing users to use the returned slug with wiki_get_* for full facts.

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

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

The description provides explicit usage guidance: 'ALWAYS search first to find the right slugs' and points to the follow-up tool (wiki_get_*) for reading full facts. This establishes a clear workflow and when to use the tool.

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

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

With no annotations, the description carries behavioral disclosure. It explains the computation scope (whole production chain), that either item or recipe slug works, and that optional parameters recompute the entire chain. It also notes server override semantics (default is this server's real settings). It does not mention error handling or return format, but for a computation tool this is fairly transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: first states the core action and outputs, second gives usage context, alternative, and optional parameters. Each part earns its place, and it is front-loaded with the main purpose.

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

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

Given the tool's complexity (7 params, nested objects, no output schema), the description covers the primary use case, distinguishes from sibling, and explains optional parameter effects. It could mention output shape but that's not strictly required. Overall it is complete enough for an agent to select and invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds useful context: slug accepts item or recipe, and character/server overrides affect the whole chain. It also clarifies the difference between module parameter and modules array. This goes beyond mere schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: flatten a recipe or craftable item to total raw materials, with labor calories, craft minutes, and step count. It distinguishes itself from sibling wiki_bom by explicitly saying wiki_bom gives intermediate sub-components, while this tool gives the raw shopping list.

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

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

Provides explicit use case: 'what does it take to make X from scratch'. It names the alternative tool (wiki_bom) for when you need intermediates, and explains when to use optional character/server overrides. This is very clear guidance.

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