Where to look for games industry research: 873 sources across ten markets, cited and free.
Scored across 6 tools
Each tool targets a clearly distinct function: landscape maps, market profiles, source retrieval, trend monitoring, source search, and search techniques. There is no ambiguity between get_source and search_sources because one retrieves a known slug while the other discovers sources.
All six tools follow a consistent verb_noun pattern: get_landscape, get_market, get_source, list_trends, search_sources, search_techniques. The verbs accurately indicate the action and the nouns clearly indicate the object, making the set predictable and easy to navigate.
Six tools is well-scoped for a research starter pack, covering the essential research workflow without redundancy. Each tool earns its place, and there is no sense of bloat or thinness.
The tool set covers the full research journey: search techniques, source discovery, source detail retrieval, market profiles, landscape reference, and current trends. Even the limitation of only ten market profiles is explicitly bridged by search_sources, so there are no obvious dead ends.
The platform and genre maps. 35 platforms — storefronts, consoles, livestreaming and UGC — with who owns each and where its data lives. 30 genres with definitions, subgenres, example games, and the terms actually used in Chinese, Korean and Japanese. Read the genre map before comparing two datasets: the industry has no shared taxonomy and this records where the vendors disagree.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | Which map. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It reveals useful data characteristics, such as ownership, data location, and recorded vendor disagreements, but it never explicitly states that the tool is read-only, return shape, or access implications. The 'get' name and 'Read the genre map' directive make the read behavior inferable.
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 three dense sentences with no filler. It front-loads the core platform/genre partition, then adds concrete supporting detail and a usage directive, making every sentence earn 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?
For a one-parameter reference tool with no output schema, this is nearly complete: it describes the content of both maps, their scope, and a key usage caveat. It could be more complete by describing the output structure or return format, but that is not critical for selecting or invoking the 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?
The schema already covers the 'kind' parameter fully with an enum and 100% coverage, so the baseline is 3. The description goes beyond the schema by explaining what each map actually contains—platform categories and ownership vs genre definitions, subgenres, examples, and regional terminology—which helps the agent choose the right enum value.
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 defines the resource ('platform and genre maps') and its scope: 35 platforms and 30 genres with specific details. It is readily distinguishable from sibling tools like get_market and get_source. It lacks an explicit verb such as 'returns', 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?
It gives a concrete usage directive: 'Read the genre map before comparing two datasets' and explains why, since the industry lacks a shared taxonomy. It does not mention alternative tools or explicitly state when the platform map should or should not be used, so it is not fully prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How to research one of 10 games markets, and the profile behind it. It opens with before_you_start, the research notes for that market: which national annuals are paid and what is free, which venues are closed or could not be verified, which figures overlap or are published on a basis that will not compare, what a weekly chart does and does not count. Then known_gaps, what the directory does not hold for that market and where to go instead. Then 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 full burden. It discloses the structure and content of the return value: 'before_you_start, known_gaps, and a sourced narrative built from claims that each carry the link they came from...' It also explains what the profile contains (market-size figure, player-population figure, etc.). This goes beyond the schema and gives the agent a detailed mental model of the output. It doesn't mention side effects or permissions, but as a read-only research tool, that's acceptable. A 4 is appropriate because it's rich but doesn't cover every edge case (e.g., error behavior).
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 paragraph but well-structured, front-loading the purpose ('How to research one of 10 games markets') before detailing the internal sections. Each sentence adds substantive information about the profile's contents. It is a bit long but not verbose; the length is justified by the tool's complexity. The structure is clear and logical, earning a 4.
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 with a multi-section return profile, and there is no output schema. The description fully explains what the tool returns: before_you_start notes, known_gaps, and a sourced narrative with specific elements (links, market-size basis, player-population definition, data location). It also covers the alternative for unsupported codes. This is complete for an agent to know what to expect and how to use it correctly. Nothing critical is missing.
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 has one parameter 'code' with an enum and a minimal description 'Market code.' The description adds meaning by explaining that the code refers to 'one of 10 games markets' and that only these ten have profiles. It reinforces that the code must be one of the enumerated values and gives context about what the code represents. With schema coverage at 100%, the baseline is 3; the description adds semantic value beyond the schema, so a 4 is warranted.
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: 'How to research one of 10 games markets, and the profile behind it.' It specifies the resource (a market profile) and the action (get/research). It also distinguishes from siblings by noting 'Only these ten have profiles — for any other market code, search_sources with a market filter is what exists,' which differentiates it from the search tool. This is a specific, non-tautological purpose statement.
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 gives usage guidance: 'Only these ten have profiles — for any other market code, search_sources with a market filter is what exists.' This tells the agent when to use this tool (for the ten listed codes) and when to use an alternative (search_sources for other codes). It provides a clear conditional and names the alternative, leaving no ambiguity about selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve one source by its slug, with everything recorded about it. Slugs come back from search_sources and are permanent — the same slug names the same source across releases, so it is what to cite.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Permanent identifier, e.g. "sensor-tower". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and it delivers: 'Retrieve' signals a safe read operation, 'with everything recorded about it' discloses the return scope, and the slug-permanence guarantee ('same slug names the same source across releases') is a genuine behavioral trait useful for citation workflows. It doesn't cover not-found error behavior, but for a one-parameter read tool that is a minor gap.
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?
Two sentences with zero filler. The core purpose is front-loaded in the first sentence, and the second sentence adds the permanence/citation context that justifies why the slug parameter is trusted. Every clause earns 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?
For a simple one-parameter tool with 100% schema coverage and no output schema, this is nearly complete: purpose, parameter origin, return scope, and a stability guarantee are all present. The only omission is what happens on a miss (not-found behavior), which is minor for a fetch-by-identifier 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?
The schema already documents slug at 100% coverage as a 'Permanent identifier', so the baseline is 3, but the description adds value beyond the schema: it reveals that slugs originate from search_sources and reinforces their permanence across releases — meaning the caller can safely persist and cite them. This is meaningful semantic enrichment rather than mere restatement.
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 ('Retrieve'), names the exact resource ('one source by its slug'), and defines the scope ('with everything recorded about it'). It clearly differentiates from the search_sources sibling by being the single-item fetch keyed on a slug, so an agent can tell them apart without opening the schema.
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 establishes the workflow by stating that slugs come back from search_sources, implicitly telling the agent to search first, then fetch by slug. It doesn't explicitly name alternatives or exclusions, and none of the sibling tools are similar single-fetch operations, but the guidance is clear enough that the usage context is well-implied rather than fully spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The 37 conversations currently moving the games industry, each with what it is, why it matters, the markets it lands in, its stage, how old the row is, and dated further reading on request. A routing map rather than a synthesis: it names arguments and points at where they are happening, and takes no position on any of them. Filter by market, stage, category or a free-text query; every filter narrows the list and none of them orders it. Rows come 14 to a page: page with offset, or name one by slug to read it with its further reading. This is the fastest-decaying data here — every row is dated, and anything older than about six months needs a refresh.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | One trend by its permanent slug, as a list returns it. Comes back with its further reading unless include_further_reading says otherwise. The other filters are ignored when this is set. | |
| limit | No | Rows per page, default 14, at most 37 without further reading and 10 with it. A page is the next rows in the order described, never the top ones — nothing here is ranked. | |
| query | No | Free text, matched against the name, what it is, why it matters, where to follow it, its category and the titles of its further reading. All words must appear. A word filter, not a semantic search: "layoffs" finds the layoff trend, a synonym the rows never use finds nothing. Omit to browse a filter instead. | |
| stage | No | Dominant is sustained mainstream coverage for a year or more. Emerging is real and accelerating. Perennial recurs cyclically. Receding was dominant and is cooling, kept so dated coverage is recognisable as dated. | |
| market | No | Trends that reach this market: tagged to it directly, reached through an EU tag, or global. Each row then says which, in market_relevance, and the list comes back closest first. Most trends in games are global and apply everywhere. | |
| offset | No | Rows to skip before the first one returned, for paging. Default 0. The note on each page says what to pass for the next. | |
| category | No | ||
| include_further_reading | No | Default false, and true when slug is given. Further reading roughly doubles a row, so at most 10 rows travel with it; ask for a row by slug to read one in full. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and handles it unusually well. It discloses non-ranking behavior, no synthesis or position-taking, pagination behavior, and the fast decay of the data with a six-month refresh guideline. This is far more transparent than typical tool 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?
Five dense sentences, each carrying a distinct fact: contents, nature, filtering behavior, pagination, and data freshness. There is no filler, and the most decision-relevant constraints are front-loaded.
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?
Despite 8 parameters, no annotations, and no output schema, the description covers row contents, filtering, pagination, slug retrieval, and freshness. The only minor gap is the absence of explicit response property names, though the schema supplies the parameter-level details an agent needs.
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 high (~88%) and the schema already documents parameters such as slug override, word-filter query semantics, and stage meanings. The description adds valuable cross-cutting semantics — every filter narrows, none orders, rows come 14 to a page — that centralize behavior the schema spreads across fields.
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 states precisely what the tool returns — the 37 conversations currently moving the games industry — and defines its nature as a routing map rather than a synthesis that takes no position. This is a specific, distinctive resource description that an agent can separate from the sibling tools even without explicit comparison.
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 gives clear operational guidance: filters narrow without ordering, paging happens by offset, and a slug retrieves a single row with further reading. It does not explicitly name sibling tools or state when not to use this one, so it falls just short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search 923 curated sources on the video games industry: press outlets, trade associations, datasets, analysts, podcasts, books, YouTube channels and communities across 26 markets. Every one was opened and read before it was described, and each result says what it lets you find out, who owns it and what it costs. This answers "where would I look for this?" — it is a directory of sources, not a source of facts, and nothing in it is ranked or scored.
| Name | Required | Description | Default |
|---|---|---|---|
| cost | No | Recorded on 533 of 923 rows — the press outlets and the individual people are not priced, so filtering on this excludes them rather than reporting them as not free. | |
| group | No | Broad kind of source. | |
| limit | No | Rows per page, default 20, maximum 50. A page is the next rows in file order, never the top ones — nothing here is ranked. | |
| query | No | Free text, matched against the name, the description and the owner. All words must appear. Omit to browse a filter instead. | |
| market | No | Market code. US, JP, KR, UK, DE, FR, CN, MENA, IT, CA have full profiles behind them; SEA, Nordics, BR, IN, MX, ES, TR, NL, AU, PL, TW, EU, LATAM, Asia, BE only tag sources. Global means the source covers everything, and "Not market specific" means market is not its axis. | |
| medium | No | What form it takes. | |
| offset | No | Rows to skip before the first one returned, for paging. Default 0. The note on each page says what to pass for the next. | |
| language | No | The language you would be reading it in. |
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. It reveals that every source was 'opened and read' before being described, that each result shows what it lets you find out, who owns it, and what it costs, and crucially that 'nothing in it is ranked or scored.' This gives agents important expectations about result quality and ordering.
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 three sentences, each earning its place: the resource scope, the credibility of curation, and the boundary of what the tool is not. It is front-loaded with the primary purpose and avoids redundant detail.
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 has 8 optional parameters and no output schema, the description covers the essential context an agent needs: result content ('what it lets you find out, who owns it and what it costs') and the non-ranking behavior. Pagination specifics are left to the schema, which is acceptable given the high schema coverage.
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 all 8 parameters are already documented in the input schema. The description adds no parameter-specific semantics beyond what the schema provides; it only lists source categories that loosely map to the group and medium enums. The baseline of 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 opens with a specific verb and resource ('Search 923 curated sources on the video games industry') and enumerates the content types (press outlets, trade associations, datasets, etc.). It further distinguishes the tool by explicitly stating it is 'a directory of sources, not a source of facts,' which separates it from siblings like get_source or search_techniques.
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 clearly frames the tool's purpose as answering 'where would I look for this?' and explicitly contrasts it with a 'source of facts,' giving agents a strong when-to-use signal. It doesn't name specific sibling tools or provide exclusion conditions, but the directory-vs-facts distinction is sufficient context for most use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
39 search techniques for games research, each with a query you can paste, what it surfaces and why it works. Includes local-language strategies for researching the Japanese, Korean and Chinese markets without reading the language. Use this before searching the open web on a games question — these are the queries that reach material a plain search buries.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Your question in your own words, for example "what are Japanese players saying about a launch". Techniques are ranked by how many of its words they mention, so a whole question works better than one keyword. | |
| market | No | Techniques for this market, plus the ones that apply everywhere. |
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. It explains the output composition: each technique includes 'a query you can paste, what it surfaces and why it works,' and it mentions the inclusion of local-language strategies. It does not discuss any side effects or prerequisites, but for an information-delivery tool this is sufficient context.
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?
Three sentences, each earning its place: the first defines the core offering, the second highlights a key feature (local-language strategies), and the third gives the when-to-use directive. The most important information is front-loaded, with no filler or repetitive phrasing.
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?
There is no output schema, so the description must indicate return values, and it does: 'each with a query you can paste, what it surfaces and why it works.' It explains the market coverage via local-language strategies and the intended use case. It could be more precise about how techniques are presented (e.g., formatting or ranking), but it is complete enough for an agent to invoke the tool correctly with clear expectations.
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%, with rich parameter descriptions: query includes an example and explains ranking behavior, and market is an exhaustive enum. The tool description adds context about local-language strategies but does not materially supplement what the schema already provides for either parameter. 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 states a specific deliverable: '39 search techniques for games research, each with a query you can paste, what it surfaces and why it works.' This clearly distinguishes it from sibling tools like search_sources by framing it as a set of reusable strategies rather than an actual search or data-retrieval operation. The 'games research' scope and the explicit 'before searching the open web' usage signal its role precisely.
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 when-to-use guidance: 'Use this before searching the open web on a games question — these are the queries that reach material a plain search buries.' It does not name sibling alternatives or state when not to use it, but the workflow ordering is clear and actionable. This is solid but slightly below the highest tier because alternatives are not explicitly contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
list_trends2 fields changedInput schema / properties / limit / descriptionPrevious value: -"Rows per page, default 16, at most 37 without further reading and 10 with it. A page is the next rows in the order described, never the top ones — nothing here is ranked."New value: +"Rows per page, default 14, at most 37 without further reading and 10 with it. A page is the next rows in the order described, never the top ones — nothing here is ranked."Input schema / properties / stage / enumPrevious value: -[
- "Dominant",
- "Emerging",
- "Perennial",
- "Receding"
-]New value: +[
+ "Dominant",
+ "Perennial",
+ "Emerging",
+ "Receding"
+]search_sources1 field changedInput schema / properties / cost / descriptionPrevious value: -"Recorded on 532 of 922 rows — the press outlets and the individual people are not priced, so filtering on this excludes them rather than reporting them as not free."New value: +"Recorded on 533 of 923 rows — the press outlets and the individual people are not priced, so filtering on this excludes them rather than reporting them as not free."search_sources2 fields changedInput schema / properties / cost / descriptionPrevious value: -"Recorded on 529 of 919 rows — the press outlets and the individual people are not priced, so filtering on this excludes them rather than reporting them as not free."New value: +"Recorded on 532 of 922 rows — the press outlets and the individual people are not priced, so filtering on this excludes them rather than reporting them as not free."Input schema / properties / medium / enumPrevious value: -[
- "News outlet",
- "Organisation",
- "Forum or community",
- "Video channel",
- "Person",
- "Podcast",
- "Data tool",
- "Book or paper",
- "Company disclosure",
- "Report or document",
- "Newsletter",
- "Research firm",
- "Link list"
-]New value: +[
+ "News outlet",
+ "Organisation",
+ "Forum or community",
+ "Video channel",
+ "Person",
+ "Data tool",
+ "Podcast",
+ "Book or paper",
+ "Company disclosure",
+ "Report or document",
+ "Newsletter",
+ "Research firm",
+ "Link list"
+]search_sources1 field changedInput schema / properties / cost / descriptionPrevious value: -"Recorded on 528 of 918 rows — the press outlets and the individual people are not priced, so filtering on this excludes them rather than reporting them as not free."New value: +"Recorded on 529 of 919 rows — the press outlets and the individual people are not priced, so filtering on this excludes them rather than reporting them as not free."list_trends1 field changedInput schema / properties / market / enumPrevious value: -[
- "US",
- "Global",
- "JP",
- "KR",
- "Not market specific",
- "UK",
- "DE",
- "FR",
- "CN",
- "MENA",
- "IT",
- "SEA",
- "CA",
- "Nordics",
- "BR",
- "IN",
- "MX",
- "ES",
- "TR",
- "NL",
- "AU",
- "PL",
- "TW",
- "EU",
- "LATAM",
- "Asia"
-]New value: +[
+ "US",
+ "Global",
+ "JP",
+ "KR",
+ "Not market specific",
+ "UK",
+ "DE",
+ "FR",
+ "CN",
+ "MENA",
+ "IT",
+ "SEA",
+ "CA",
+ "Nordics",
+ "BR",
+ "IN",
+ "MX",
+ "ES",
+ "TR",
+ "NL",
+ "AU",
+ "PL",
+ "TW",
+ "EU",
+ "LATAM",
+ "Asia",
+ "BE"
+]search_sources4 fields changedInput schema / properties / cost / descriptionPrevious value: -"Recorded on 527 of 917 rows — the press outlets and the individual people are not priced, so filtering on this excludes them rather than reporting them as not free."New value: +"Recorded on 528 of 918 rows — the press outlets and the individual people are not priced, so filtering on this excludes them rather than reporting them as not free."Input schema / properties / language / enumPrevious value: -[
- "English",
- "Japanese",
- "Korean",
- "German",
- "French",
- "Spanish",
- "Portuguese",
- "Arabic",
- "Italian",
- "Chinese",
- "Turkish",
- "Polish",
- "Traditional Chinese",
- "Dutch",
- "Bahasa Indonesia",
- "Multilingual",
- "Swedish",
- "Vietnamese",
- "Finnish",
- "Danish",
- "Norwegian",
- "Thai",
- "Hindi",
- "Indonesian",
- "Malay"
-]New value: +[
+ "English",
+ "Japanese",
+ "Korean",
+ "German",
+ "French",
+ "Spanish",
+ "Portuguese",
+ "Arabic",
+ "Italian",
+ "Chinese",
+ "Turkish",
+ "Dutch",
+ "Polish",
+ "Traditional Chinese",
+ "Bahasa Indonesia",
+ "Multilingual",
+ "Swedish",
+ "Vietnamese",
+ "Finnish",
+ "Danish",
+ "Norwegian",
+ "Thai",
+ "Hindi",
+ "Indonesian",
+ "Malay"
+]Input schema / properties / market / descriptionPrevious value: -"Market code. US, JP, KR, UK, DE, FR, CN, MENA, IT, CA have full profiles behind them; SEA, Nordics, BR, IN, MX, ES, TR, NL, AU, PL, TW, EU, LATAM, Asia only tag sources. Global means the source covers everything, and \"Not market specific\" means market is not its axis."New value: +"Market code. US, JP, KR, UK, DE, FR, CN, MENA, IT, CA have full profiles behind them; SEA, Nordics, BR, IN, MX, ES, TR, NL, AU, PL, TW, EU, LATAM, Asia, BE only tag sources. Global means the source covers everything, and \"Not market specific\" means market is not its axis."Input schema / properties / market / enumPrevious value: -[
- "US",
- "Global",
- "JP",
- "KR",
- "Not market specific",
- "UK",
- "DE",
- "FR",
- "CN",
- "MENA",
- "IT",
- "SEA",
- "CA",
- "Nordics",
- "BR",
- "IN",
- "MX",
- "ES",
- "TR",
- "NL",
- "AU",
- "PL",
- "TW",
- "EU",
- "LATAM",
- "Asia"
-]New value: +[
+ "US",
+ "Global",
+ "JP",
+ "KR",
+ "Not market specific",
+ "UK",
+ "DE",
+ "FR",
+ "CN",
+ "MENA",
+ "IT",
+ "SEA",
+ "CA",
+ "Nordics",
+ "BR",
+ "IN",
+ "MX",
+ "ES",
+ "TR",
+ "NL",
+ "AU",
+ "PL",
+ "TW",
+ "EU",
+ "LATAM",
+ "Asia",
+ "BE"
+]search_techniques1 field changedInput schema / properties / market / enumPrevious value: -[
- "US",
- "Global",
- "JP",
- "KR",
- "Not market specific",
- "UK",
- "DE",
- "FR",
- "CN",
- "MENA",
- "IT",
- "SEA",
- "CA",
- "Nordics",
- "BR",
- "IN",
- "MX",
- "ES",
- "TR",
- "NL",
- "AU",
- "PL",
- "TW",
- "EU",
- "LATAM",
- "Asia"
-]New value: +[
+ "US",
+ "Global",
+ "JP",
+ "KR",
+ "Not market specific",
+ "UK",
+ "DE",
+ "FR",
+ "CN",
+ "MENA",
+ "IT",
+ "SEA",
+ "CA",
+ "Nordics",
+ "BR",
+ "IN",
+ "MX",
+ "ES",
+ "TR",
+ "NL",
+ "AU",
+ "PL",
+ "TW",
+ "EU",
+ "LATAM",
+ "Asia",
+ "BE"
+]list_trends1 field changedInput schema / properties / limit / descriptionPrevious value: -"Rows per page, default 20, at most 37 without further reading and 10 with it. A page is the next rows in the order described, never the top ones — nothing here is ranked."New value: +"Rows per page, default 16, at most 37 without further reading and 10 with it. A page is the next rows in the order described, never the top ones — nothing here is ranked."search_sources1 field changedInput schema / properties / cost / descriptionPrevious value: -"Recorded on 524 of 914 rows — the press outlets and the individual people are not priced, so filtering on this excludes them rather than reporting them as not free."New value: +"Recorded on 527 of 917 rows — the press outlets and the individual people are not priced, so filtering on this excludes them rather than reporting them as not free."search_sources2 fields changedInput schema / properties / cost / descriptionPrevious value: -"Recorded on 497 of 887 rows — the press outlets and the individual people are not priced, so filtering on this excludes them rather than reporting them as not free."New value: +"Recorded on 524 of 914 rows — the press outlets and the individual people are not priced, so filtering on this excludes them rather than reporting them as not free."Input schema / properties / group / enumPrevious value: -[
- "Press",
- "Media",
- "Institutions",
- "Data",
- "People",
- "Communities"
-]New value: +[
+ "Press",
+ "Media",
+ "Institutions",
+ "Data",
+ "Communities",
+ "People"
+]search_sources1 field changedInput schema / properties / cost / descriptionPrevious value: -"Recorded on 496 of 886 rows — the press outlets and the individual people are not priced, so filtering on this excludes them rather than reporting them as not free."New value: +"Recorded on 497 of 887 rows — the press outlets and the individual people are not priced, so filtering on this excludes them rather than reporting them as not free."search_techniques1 field changedInput schema / properties / query / descriptionPrevious value: -"Free text over the technique and how it works."New value: +"Your question in your own words, for example \"what are Japanese players saying about a launch\". Techniques are ranked by how many of its words they mention, so a whole question works better than one keyword."list_trends1 field changedInput schema / properties / market / enumPrevious value: -[
- "US",
- "Global",
- "JP",
- "KR",
- "UK",
- "Not market specific",
- "DE",
- "FR",
- "CN",
- "MENA",
- "IT",
- "SEA",
- "CA",
- "Nordics",
- "BR",
- "IN",
- "MX",
- "ES",
- "TR",
- "NL",
- "AU",
- "PL",
- "TW",
- "EU",
- "LATAM",
- "Asia"
-]New value: +[
+ "US",
+ "Global",
+ "JP",
+ "KR",
+ "Not market specific",
+ "UK",
+ "DE",
+ "FR",
+ "CN",
+ "MENA",
+ "IT",
+ "SEA",
+ "CA",
+ "Nordics",
+ "BR",
+ "IN",
+ "MX",
+ "ES",
+ "TR",
+ "NL",
+ "AU",
+ "PL",
+ "TW",
+ "EU",
+ "LATAM",
+ "Asia"
+]search_sources4 fields changedInput schema / properties / cost / descriptionPrevious value: -"Recorded on 487 of 874 rows — the press outlets and the individual people are not priced, so filtering on this excludes them rather than reporting them as not free."New value: +"Recorded on 496 of 886 rows — the press outlets and the individual people are not priced, so filtering on this excludes them rather than reporting them as not free."Input schema / properties / limit / descriptionPrevious value: -"Maximum results, default 20, maximum 100."New value: +"Rows per page, default 20, maximum 50. A page is the next rows in file order, never the top ones — nothing here is ranked."Input schema / properties / market / enumPrevious value: -[
- "US",
- "Global",
- "JP",
- "KR",
- "UK",
- "Not market specific",
- "DE",
- "FR",
- "CN",
- "MENA",
- "IT",
- "SEA",
- "CA",
- "Nordics",
- "BR",
- "IN",
- "MX",
- "ES",
- "TR",
- "NL",
- "AU",
- "PL",
- "TW",
- "EU",
- "LATAM",
- "Asia"
-]New value: +[
+ "US",
+ "Global",
+ "JP",
+ "KR",
+ "Not market specific",
+ "UK",
+ "DE",
+ "FR",
+ "CN",
+ "MENA",
+ "IT",
+ "SEA",
+ "CA",
+ "Nordics",
+ "BR",
+ "IN",
+ "MX",
+ "ES",
+ "TR",
+ "NL",
+ "AU",
+ "PL",
+ "TW",
+ "EU",
+ "LATAM",
+ "Asia"
+]Input schema / properties / offsetAdded value: +{
+ "description": "Rows to skip before the first one returned, for paging. Default 0. The note on each page says what to pass for the next.",
+ "type": "number"
+}search_techniques1 field changedInput schema / properties / market / enumPrevious value: -[
- "US",
- "Global",
- "JP",
- "KR",
- "UK",
- "Not market specific",
- "DE",
- "FR",
- "CN",
- "MENA",
- "IT",
- "SEA",
- "CA",
- "Nordics",
- "BR",
- "IN",
- "MX",
- "ES",
- "TR",
- "NL",
- "AU",
- "PL",
- "TW",
- "EU",
- "LATAM",
- "Asia"
-]New value: +[
+ "US",
+ "Global",
+ "JP",
+ "KR",
+ "Not market specific",
+ "UK",
+ "DE",
+ "FR",
+ "CN",
+ "MENA",
+ "IT",
+ "SEA",
+ "CA",
+ "Nordics",
+ "BR",
+ "IN",
+ "MX",
+ "ES",
+ "TR",
+ "NL",
+ "AU",
+ "PL",
+ "TW",
+ "EU",
+ "LATAM",
+ "Asia"
+]list_trends1 field changedInput schema / properties / limit / descriptionPrevious value: -"Rows per page, default 12, at most 37 without further reading and 10 with it. A page is the next rows in the order described, never the top ones — nothing here is ranked."New value: +"Rows per page, default 20, at most 37 without further reading and 10 with it. A page is the next rows in the order described, never the top ones — nothing here is ranked."list_trends4 fields changedInput schema / properties / include_further_reading / descriptionPrevious value: -"Default true. Pass false to drop the further_reading list from each row, which is about a third of the payload, when all you need is the trends themselves."New value: +"Default false, and true when slug is given. Further reading roughly doubles a row, so at most 10 rows travel with it; ask for a row by slug to read one in full."Input schema / properties / limit / descriptionPrevious value: -"Maximum results, default all 37. A subset is the first rows in the order described, never the top ones — nothing here is ranked."New value: +"Rows per page, default 12, at most 37 without further reading and 10 with it. A page is the next rows in the order described, never the top ones — nothing here is ranked."Input schema / properties / offsetAdded value: +{
+ "description": "Rows to skip before the first one returned, for paging. Default 0. The note on each page says what to pass for the next.",
+ "type": "number"
+}Input schema / properties / slugAdded value: +{
+ "description": "One trend by its permanent slug, as a list returns it. Comes back with its further reading unless include_further_reading says otherwise. The other filters are ignored when this is set.",
+ "type": "string"
+}search_sources1 field changedInput schema / properties / cost / descriptionPrevious value: -"Recorded on 486 of 873 rows — the press outlets and the individual people are not priced, so filtering on this excludes them rather than reporting them as not free."New value: +"Recorded on 487 of 874 rows — the press outlets and the individual people are not priced, so filtering on this excludes them rather than reporting them as not free."list_trends4 fields changedInput schema / properties / include_further_readingAdded value: +{
+ "description": "Default true. Pass false to drop the further_reading list from each row, which is about a third of the payload, when all you need is the trends themselves.",
+ "type": "boolean"
+}Input schema / properties / limitAdded value: +{
+ "description": "Maximum results, default all 37. A subset is the first rows in the order described, never the top ones — nothing here is ranked.",
+ "type": "number"
+}Input schema / properties / market / descriptionPrevious value: -"Only trends landing in this market."New value: +"Trends that reach this market: tagged to it directly, reached through an EU tag, or global. Each row then says which, in market_relevance, and the list comes back closest first. Most trends in games are global and apply everywhere."Input schema / properties / queryAdded value: +{
+ "description": "Free text, matched against the name, what it is, why it matters, where to follow it, its category and the titles of its further reading. All words must appear. A word filter, not a semantic search: \"layoffs\" finds the layoff trend, a synonym the rows never use finds nothing. Omit to browse a filter instead.",
+ "type": "string"
+}get_landscapeget_marketget_sourcelist_trendssearch_sourcessearch_techniquesSearch 300+ game industry reports with hybrid search, claims, charts, and citations.
Search 438 game outsourcing studios by service, country, engine and platform. No API key.
The gaming attention graph: Steam players, Twitch live viewers, aggro ratio, hype, history.
Market research and competitive intelligence for startup ideas - every finding source-linked.
Add one secure layer between your agents and this server.
