A full profile of one of 10 games markets: a sourced narrative built from claims that each carry the link they came from, a market-size figure with the basis it was published on, a player-population figure with the definition of who was counted, and where that market's data lives. Only these ten have profiles — for any other market code, search_sources with a market filter is what exists.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Market code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses what the tool returns (claims with links, market-size basis, population definition, data location) and its coverage boundary (only ten markets). It does not mention error behavior for invalid codes, but the schema enum already constrains that, so the gap is minor.
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 front-loads the core concept ('A full profile of one of 10 games markets') and then lists the returned components in a structured sequence. It is slightly long, but every clause adds concrete information, and the final sentence adds an important usage boundary.
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 appropriately explains return values: claims with links, market-size figure with basis, population figure with definition, and data location. Together with the enum schema and the explicit alternative for other market codes, an agent has enough to call the tool correctly. It lacks examples or specific formatting details, but these are not essential for a one-parameter retrieval 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% — the single 'code' parameter is fully documented with an enum of ten values. The description adds context that these codes correspond to market profiles and that unsupported codes should go elsewhere, but it does not add format, type, or semantic detail beyond the schema. Baseline 3 is appropriate.
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 names a specific resource ('a full profile of one of 10 games markets') and enumerates the contents: sourced narrative, market-size figure, player-population figure, and data location. It also differentiates itself from search_sources by noting that only these ten market codes have profiles, making the tool's scope unmistakable.
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 when to use this tool versus the alternative: 'Only these ten have profiles — for any other market code, search_sources with a market filter is what exists.' This gives an agent a clear routing rule with no inference required.
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.
Each tool targets a distinct resource or action: landscape maps, market profiles, source retrieval, trend listings, source search, and technique search. There is no overlap in purpose, and the descriptions clearly differentiate their roles.
All tool names follow a consistent verb_noun pattern using snake_case (get_, list_, search_). This predictable structure makes the API easy to navigate and reduces cognitive load.
With 6 tools, the surface is well-scoped for a starter pack. Each tool covers a distinct aspect of games research, and the count is within the ideal 3-15 range, neither too thin nor overwhelming.
The tool set covers the core research workflow: understanding landscape, retrieving market profiles, citing sources, exploring trends, and finding sources/techniques. The only minor gap is the absence of a dedicated list of all available markets (get_market requires a code), though search_sources partly fills this, making it workable.
