Full-text search the Eco game wiki (items, recipes, skills, animals, plants, biomes, guides). Returns ranked matches with name, kind, canonical url and a snippet.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (1-50, default 15). | |
| query | Yes | The search query. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose the return format (ranked matches with name, kind, URL, snippet) and the full-text nature. However, it does not disclose pagination, search syntax, or edge-case behavior, leaving gaps.
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 efficiently states the operation, scope, and return fields without 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 simple 2-parameter tool with no annotations or output schema, the description covers the search domain, content types, and return format. It omits edge-case details but is otherwise sufficient for selecting this tool.
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% (query required, limit optional with range). The description does not add any parameter-level detail beyond the schema, so baseline 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 a full-text search tool for the Eco game wiki, listing content types and return format. It does not explicitly differentiate from the sibling wiki_search, so it stops short of a 5.
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 usage for searching wiki content but provides no explicit guidance on when to use this tool versus alternatives like wiki_search. There are 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.
Add one secure layer between your agents and this server.
Most tools have distinct purposes (fetch, wiki_get, wiki_rank, wiki_calc, etc.), but search and wiki_search are clearly duplicated full-text search tools, and fetch vs wiki_get could be confused initially. Descriptions help but the overlap is notable.
Naming is inconsistent: 'fetch' and 'search' lack the 'wiki_' prefix used by others, and there is a mix of verb-based (get, rank, calc) and noun-based (bom, contract_basics) names. Having both 'search' and 'wiki_search' for the same functionality is a clear naming violation.
10 tools is within the ideal 3-15 range for a wiki server, covering search, retrieval, analytics, and recipe calculations. However, one tool is essentially redundant (search vs wiki_search), making the count slightly padded.
The tool surface covers the core wiki workflow: search, fetch markdown, read structured facts, rank/aggregate numeric data, and compute recipe-related metrics (BOM, raw materials, exact calc). Minor gaps like listing all entities of a kind without ranking, but overall no dead ends.