Where to look for games industry research: 873 sources across ten markets, cited and free.
Scored across 6 tools
Each tool has a recognizable role: two reference getters (landscape taxonomy vs. per-market profile), one record fetch by slug (get_source), and three searches over different corpora (sources, trends, techniques). The only real friction is get_market vs. search_sources with a market filter — the description itself has to explain that fallback — and get_landscape vs. get_market both read as 'get some reference data' until the descriptions disambiguate them.
A clean verb_noun pattern throughout: get_* for single/whole reference objects, list_* and search_* for queryable collections. Singular vs. plural nouns track cardinality correctly (get_source one, search_sources many), which reinforces rather than muddies the pattern.
Six tools is well-scoped for a research starter pack, and each covers a genuinely different research move: orient (landscape), go deep on a market, find a source, fetch a source, follow conversations, and learn search craft. Nothing looks like filler or a duplicate entry point.
The surface covers orientation, discovery, retrieval and method, with clear cross-links (slugs from search_sources feed get_source; trends named by slug). The main gap is depth of coverage: only 12 markets get profiles and there is no tool to enumerate available markets or browse trends outside the current 50, so agents hitting an unprofiled market fall back to a generic source search.
The platform and genre maps. 38 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?
With no annotations, the description carries the full disclosure burden and does well: it reveals the scale (38/30 entries), what each record carries (ownership, data location, subgenres, example games, CJK terminology), and a caveat that vendors disagree on taxonomy. It does not cover freshness, caching, or format of the response, keeping it short of a 5.
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 dense sentences, front-loaded with the resource statement then the inventory then the usage rule. Every sentence carries information, though the inventory sentence is heavy and the tool's retrieval verb is left implicit.
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 convey what is returned; it does so by enumerating the fields in each map (ownership, data location, definitions, subgenres, terms). For a single-enum reference lookup this is nearly complete, with only response format and pagination left unstated.
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 enum values self-document, but the description adds genuine meaning beyond the schema by explaining what each enum selects: 'platforms' maps to storefronts/consoles/livestreaming/UGC with ownership, and 'genres' maps to definitions and multilingual terms. Baseline 3 is exceeded because it characterizes each option.
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 the two concrete resources it returns — 'The platform and genre maps' — and enumerates their contents (38 platforms, 30 genres with definitions and multilingual terms). This is far more specific than a tautology and clearly separable in content from siblings like get_market or get_source, though it never explicitly contrasts itself with them.
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 when-to-use condition: 'Read the genre map before comparing two datasets' with a reason (no shared taxonomy, records vendor disagreement). This is real routing guidance, but it covers only the genres branch and offers no exclusion or alternative-selection advice for the platforms branch or sibling tools.
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 12 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 twelve 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?
With no annotations, the description carries the disclosure burden, and it does unusually well: it previews the profile sections and volunteers limitations (unverified or closed venues, overlapping or non-comparable figures, known_gaps and where to go instead). It does not state read-only nature, auth, or rate limits, but for a read-style 'get' tool the data-caveat disclosure is genuinely informative.
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?
Purpose is front-loaded in the first sentence, which is good, but the rest is a long chained narrative ('which national annuals... which venues... which figures...') whose clauses, while informative, are not tightly organized. Roughly 110 words for a one-parameter tool is heavier than it needs to be.
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 bears full responsibility for explaining return values, and it does: it enumerates the profile's components (before_you_start, known_gaps, sourced narrative, market-size and player-population figures with their bases). An agent knows what it will receive and what the data does not cover.
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 single `code` parameter is fully enumerated, so the schema already defines the input; the baseline is 3. The description adds only the count of supported markets (twelve), which the enum already conveys, and adds no syntax or format detail.
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 concrete resource — a market profile for one of 12 games markets — and the enum of codes reinforces the scope. It clearly differentiates from siblings by stating only these twelve have profiles while any other code routes to search_sources. The opening 'How to research' is slightly indirect, but the substance is specific.
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 an explicit when-to-use (the 12 enumerated market codes) and an explicit alternative for everything else ('for any other market code, search_sources with a market filter is what exists'). That is a named sibling and the precise condition that selects it, leaving nothing to inference.
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 50 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 where it sits on the Three Horizons: H1, the current system running down, H2, the transition and its four groups, H3, the emerging future, or perennial ground. The placements are an editorial reading, not a score, and every answer carries the key to them in horizons. 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 horizon, group, market, stage, category or a free-text query; every filter narrows the list and none of them ranks it. Rows come in the order /trends reads them, 14 to a page: page with offset. Name one by slug to read it in full, with its further reading and its claims: a dated timeline, figures, status, consequences, objections, talk and what to watch, each with the link it came from. A claim marked talk: true cites a player community: it shows what players are saying, which moves this industry, and weighs less than reporting. Never quote it as an event or a figure. A claim carrying retired came off its page on that date and is kept as the record: true when written, no longer part of the 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 claims, and with its further reading unless include_further_reading says otherwise. The other filters are ignored when this is set. | |
| group | No | One of the four groups inside h2: shifts that make room for h3, rules being rewritten, moves that prolong h1, and bets that stalled. Only h2 trends carry one. | |
| limit | No | Rows per page, default and at most 14 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, its horizon label and line, 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. | |
| horizon | No | h1 is the currently dominant system, losing its fit. h3 is the early working examples of what may replace it. h2 is the turbulent ground between them, sorted into four groups. perennial is the pressures every horizon has to answer. | |
| 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 at all, the description carries the full behavioral burden and does so unusually well: results are unranked and returned in /trends order, 14 rows per page (10 with further reading), placements are 'an editorial reading, not a score', and the tool is 'a routing map rather than a synthesis' that takes no position. It also discloses two non-obvious data caveats an agent could otherwise misuse: talk:true claims are player chatter that must never be quoted as an event or figure, and retired claims are archival records, not live rows.
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 content is high-value and front-loaded with what the tool is, but it is delivered as a single dense paragraph of chained clauses with em-dashes and colons. The claim-taxonomy detail (talk, retired, horizons key) occupies substantial space that could be tightened or separated. Efficient in word count per idea, poor in scannability.
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 10 parameters, no output schema and no annotations, the description correctly compensates by describing the row shape, claim structure, pagination note and freshness decay. Nothing an agent needs to call it correctly appears to be missing. The only residual gap is that error or empty-result behavior is unaddressed.
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 90%, so nearly every parameter is already documented, including the enum meanings for horizon, stage, market and group. The description reinforces the slug deep-read behavior and the non-ranking semantics of paging and filters, but adds little per-parameter detail the schema does not already state. 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 opening sentence names a specific verb and resource with scope: 'The 50 conversations currently moving the games industry', plus an enumeration of the fields each row carries. An agent knows immediately this is the trend index rather than a source or market lookup. It never names or contrasts the siblings (get_landscape, get_market), 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?
Usage is well signposted: filter to browse ('every filter narrows the list and none of them ranks it'), 'page with offset', and 'Name one by slug to read it in full' for the deep read. The freshness warning ('anything older than about six months needs a refresh') tells the agent when results may be stale. It gives no explicit when-not-to-use or routing to the sibling tools, which is the only gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search 995 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 592 of 995 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, IN, BR, FR, CN, MENA, IT, CA have full profiles behind them; SEA, Nordics, 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, the description carries the full burden and usefully discloses curation, the kind of information each result contains, and that nothing is ranked or scored. It does not discuss authentication, rate limits, or full pagination behavior, but those are partly covered by the schema and less critical for this read-only search tool.
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 and each sentence establishes scope, curation quality, result content, or a boundary. It is slightly dense and restates the non-ranking idea, but it remains appropriately sized for a search tool.
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 an eight-filter search tool with no output schema, the description gives enough purpose, corpus scope, result content, and non-ranking caveat to call it correctly. The main omission is sibling routing, while filter and paging details are well covered by the schema.
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%, with all eight filters documented in detail, including enum meanings and paging behavior. The description adds little parameter-specific meaning beyond noting that results include cost and owner information and that ordering is not ranked, so 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 opening clause names a specific verb (Search) and resource (995 curated sources), then narrows scope to the video games industry, source types, and 26 markets. It also draws a clear conceptual boundary as a directory of sources rather than a source of facts, which helps distinguish it from fact/trend tools, though it does not name siblings.
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 clear use case in "where would I look for this?" and an exclusion in "not a source of facts." However, it never names alternatives such as get_source or search_techniques or explains when to choose them, so routing guidance is incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
44 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, the description carries the full burden, and it delivers the most important behavioral fact: the output is techniques with queries and rationales, not search results or answers. It also discloses that coverage includes non-English market strategies, which an agent could not infer otherwise. It does not discuss result limits, ranking of techniques (only the schema mentions that), or whether the catalog is static.
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 tight sentences, with the payload (44 techniques and their anatomy) front-loaded and the usage trigger last. Slightly promotional phrasing ('the queries that reach material a plain search buries') costs a little precision but is not padding.
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 simple (two optional parameters, no output schema, no annotations), and the description covers what it returns, why it is useful, and when to call it. An agent can invoke it correctly without further reading. Nothing about result size or how to consume the techniques afterwards is stated, though that is a minor gap for a read-only lookup.
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 both parameters are already fully documented, establishing a baseline of 3. The description adds a little context for the market parameter by explaining that local-language strategies exist for JP, KR and CN, but it says nothing about the free-text query beyond what the schema already states about ranking by word overlap.
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 concretely states what the tool returns: a set of 44 search techniques, each with a pasteable query, what it surfaces, and why it works. That makes clear it is a technique catalog rather than a live search, which is the crucial distinction. It does not name or rule out any sibling (search_sources, get_source, get_market, list_trends, get_landscape), so sibling differentiation is only implied by 'before searching the open web.'
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?
Explicit timing guidance is given: 'Use this before searching the open web on a games question,' which frames the tool as a pre-search step. A specific use case (researching the JP/KR/CN markets without language skills) is also named. It stops short of stating when NOT to use it or naming which sibling to pick instead once techniques are in hand.
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_trends1 field changedInput schema / properties / market / enumPrevious value: -[
- "US",
- "Global",
- "JP",
- "KR",
- "Not market specific",
- "UK",
- "DE",
- "IN",
- "BR",
- "FR",
- "CN",
- "MENA",
- "IT",
- "SEA",
- "CA",
- "Nordics",
- "MX",
- "ES",
- "TR",
- "NL",
- "AU",
- "PL",
- "TW",
- "EU",
- "LATAM",
- "Asia",
- "BE"
-]New value: +[
+ "US",
+ "Global",
+ "JP",
+ "KR",
+ "UK",
+ "Not market specific",
+ "DE",
+ "IN",
+ "BR",
+ "FR",
+ "CN",
+ "MENA",
+ "IT",
+ "SEA",
+ "CA",
+ "Nordics",
+ "MX",
+ "ES",
+ "TR",
+ "NL",
+ "AU",
+ "PL",
+ "TW",
+ "EU",
+ "LATAM",
+ "Asia",
+ "BE"
+]search_sources2 fields changedInput schema / properties / cost / descriptionPrevious value: -"Recorded on 586 of 989 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 592 of 995 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 / market / enumPrevious value: -[
- "US",
- "Global",
- "JP",
- "KR",
- "Not market specific",
- "UK",
- "DE",
- "IN",
- "BR",
- "FR",
- "CN",
- "MENA",
- "IT",
- "SEA",
- "CA",
- "Nordics",
- "MX",
- "ES",
- "TR",
- "NL",
- "AU",
- "PL",
- "TW",
- "EU",
- "LATAM",
- "Asia",
- "BE"
-]New value: +[
+ "US",
+ "Global",
+ "JP",
+ "KR",
+ "UK",
+ "Not market specific",
+ "DE",
+ "IN",
+ "BR",
+ "FR",
+ "CN",
+ "MENA",
+ "IT",
+ "SEA",
+ "CA",
+ "Nordics",
+ "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",
- "IN",
- "BR",
- "FR",
- "CN",
- "MENA",
- "IT",
- "SEA",
- "CA",
- "Nordics",
- "MX",
- "ES",
- "TR",
- "NL",
- "AU",
- "PL",
- "TW",
- "EU",
- "LATAM",
- "Asia",
- "BE"
-]New value: +[
+ "US",
+ "Global",
+ "JP",
+ "KR",
+ "UK",
+ "Not market specific",
+ "DE",
+ "IN",
+ "BR",
+ "FR",
+ "CN",
+ "MENA",
+ "IT",
+ "SEA",
+ "CA",
+ "Nordics",
+ "MX",
+ "ES",
+ "TR",
+ "NL",
+ "AU",
+ "PL",
+ "TW",
+ "EU",
+ "LATAM",
+ "Asia",
+ "BE"
+]search_sources1 field changedInput schema / properties / cost / descriptionPrevious value: -"Recorded on 583 of 986 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 586 of 989 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 579 of 981 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 583 of 986 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",
- "Chinese",
- "Italian",
- "Turkish",
- "Dutch",
- "Polish",
- "Traditional Chinese",
- "Multilingual",
- "Bahasa Indonesia",
- "Swedish",
- "Hindi",
- "Vietnamese",
- "Finnish",
- "Danish",
- "Norwegian",
- "Thai",
- "Indonesian",
- "Malay"
-]New value: +[
+ "English",
+ "Japanese",
+ "Korean",
+ "German",
+ "French",
+ "Spanish",
+ "Portuguese",
+ "Arabic",
+ "Chinese",
+ "Italian",
+ "Turkish",
+ "Dutch",
+ "Polish",
+ "Traditional Chinese",
+ "Multilingual",
+ "Bahasa Indonesia",
+ "Hindi",
+ "Swedish",
+ "Vietnamese",
+ "Finnish",
+ "Danish",
+ "Norwegian",
+ "Thai",
+ "Indonesian",
+ "Malay"
+]list_trends1 field changedInput schema / properties / category / enumPrevious value: -[
- "Money & business model",
- "Platform & distribution",
- "Culture & audience",
- "Regulation, safety & age",
- "Geography & power",
- "Technology"
-]New value: +[
+ "Money & business model",
+ "Culture & audience",
+ "Platform & distribution",
+ "Regulation, safety & age",
+ "Geography & power",
+ "Technology"
+]list_trends1 field changedInput schema / properties / category / enumPrevious value: -[
- "Money & business model",
- "Platform & distribution",
- "Regulation, safety & age",
- "Culture & audience",
- "Geography & power",
- "Technology"
-]New value: +[
+ "Money & business model",
+ "Platform & distribution",
+ "Culture & audience",
+ "Regulation, safety & age",
+ "Geography & power",
+ "Technology"
+]search_sources2 fields changedInput schema / properties / cost / descriptionPrevious value: -"Recorded on 576 of 978 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 579 of 981 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",
- "Dutch",
- "Polish",
- "Traditional Chinese",
- "Multilingual",
- "Bahasa Indonesia",
- "Swedish",
- "Hindi",
- "Vietnamese",
- "Finnish",
- "Danish",
- "Norwegian",
- "Thai",
- "Indonesian",
- "Malay"
-]New value: +[
+ "English",
+ "Japanese",
+ "Korean",
+ "German",
+ "French",
+ "Spanish",
+ "Portuguese",
+ "Arabic",
+ "Chinese",
+ "Italian",
+ "Turkish",
+ "Dutch",
+ "Polish",
+ "Traditional Chinese",
+ "Multilingual",
+ "Bahasa Indonesia",
+ "Swedish",
+ "Hindi",
+ "Vietnamese",
+ "Finnish",
+ "Danish",
+ "Norwegian",
+ "Thai",
+ "Indonesian",
+ "Malay"
+]list_trends1 field changedInput schema / properties / category / enumPrevious value: -[
- "Money & business model",
- "Platform & distribution",
- "Culture & audience",
- "Regulation, safety & age",
- "Geography & power",
- "Technology"
-]New value: +[
+ "Money & business model",
+ "Platform & distribution",
+ "Regulation, safety & age",
+ "Culture & audience",
+ "Geography & power",
+ "Technology"
+]search_sources1 field changedInput schema / properties / cost / descriptionPrevious value: -"Recorded on 575 of 977 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 576 of 978 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 / category / enumPrevious value: -[
- "Money & business model",
- "Regulation, safety & age",
- "Platform & distribution",
- "Culture & audience",
- "Geography & power",
- "Technology"
-]New value: +[
+ "Money & business model",
+ "Platform & distribution",
+ "Culture & audience",
+ "Regulation, safety & age",
+ "Geography & power",
+ "Technology"
+]get_market1 field changedInput schema / properties / code / enumPrevious value: -[
- "US",
- "JP",
- "KR",
- "UK",
- "DE",
- "BR",
- "FR",
- "CN",
- "MENA",
- "IT",
- "CA"
-]New value: +[
+ "US",
+ "JP",
+ "KR",
+ "UK",
+ "DE",
+ "IN",
+ "BR",
+ "FR",
+ "CN",
+ "MENA",
+ "IT",
+ "CA"
+]list_trends1 field changedInput schema / properties / market / enumPrevious value: -[
- "US",
- "Global",
- "JP",
- "KR",
- "Not market specific",
- "UK",
- "DE",
- "BR",
- "FR",
- "CN",
- "MENA",
- "IT",
- "SEA",
- "CA",
- "Nordics",
- "IN",
- "MX",
- "ES",
- "TR",
- "NL",
- "AU",
- "PL",
- "TW",
- "EU",
- "LATAM",
- "Asia",
- "BE"
-]New value: +[
+ "US",
+ "Global",
+ "JP",
+ "KR",
+ "Not market specific",
+ "UK",
+ "DE",
+ "IN",
+ "BR",
+ "FR",
+ "CN",
+ "MENA",
+ "IT",
+ "SEA",
+ "CA",
+ "Nordics",
+ "MX",
+ "ES",
+ "TR",
+ "NL",
+ "AU",
+ "PL",
+ "TW",
+ "EU",
+ "LATAM",
+ "Asia",
+ "BE"
+]search_sources5 fields changedInput schema / properties / cost / descriptionPrevious value: -"Recorded on 560 of 957 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 575 of 977 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",
- "Dutch",
- "Polish",
- "Traditional Chinese",
- "Multilingual",
- "Bahasa Indonesia",
- "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",
+ "Multilingual",
+ "Bahasa Indonesia",
+ "Swedish",
+ "Hindi",
+ "Vietnamese",
+ "Finnish",
+ "Danish",
+ "Norwegian",
+ "Thai",
+ "Indonesian",
+ "Malay"
+]Input schema / properties / market / descriptionPrevious value: -"Market code. US, JP, KR, UK, DE, BR, FR, CN, MENA, IT, CA have full profiles behind them; SEA, Nordics, 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."New value: +"Market code. US, JP, KR, UK, DE, IN, BR, FR, CN, MENA, IT, CA have full profiles behind them; SEA, Nordics, 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",
- "BR",
- "FR",
- "CN",
- "MENA",
- "IT",
- "SEA",
- "CA",
- "Nordics",
- "IN",
- "MX",
- "ES",
- "TR",
- "NL",
- "AU",
- "PL",
- "TW",
- "EU",
- "LATAM",
- "Asia",
- "BE"
-]New value: +[
+ "US",
+ "Global",
+ "JP",
+ "KR",
+ "Not market specific",
+ "UK",
+ "DE",
+ "IN",
+ "BR",
+ "FR",
+ "CN",
+ "MENA",
+ "IT",
+ "SEA",
+ "CA",
+ "Nordics",
+ "MX",
+ "ES",
+ "TR",
+ "NL",
+ "AU",
+ "PL",
+ "TW",
+ "EU",
+ "LATAM",
+ "Asia",
+ "BE"
+]Input schema / properties / medium / enumPrevious value: -[
- "News outlet",
- "Organisation",
- "Forum or community",
- "Person",
- "Video channel",
- "Data tool",
- "Podcast",
- "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_techniques1 field changedInput schema / properties / market / enumPrevious value: -[
- "US",
- "Global",
- "JP",
- "KR",
- "Not market specific",
- "UK",
- "DE",
- "BR",
- "FR",
- "CN",
- "MENA",
- "IT",
- "SEA",
- "CA",
- "Nordics",
- "IN",
- "MX",
- "ES",
- "TR",
- "NL",
- "AU",
- "PL",
- "TW",
- "EU",
- "LATAM",
- "Asia",
- "BE"
-]New value: +[
+ "US",
+ "Global",
+ "JP",
+ "KR",
+ "Not market specific",
+ "UK",
+ "DE",
+ "IN",
+ "BR",
+ "FR",
+ "CN",
+ "MENA",
+ "IT",
+ "SEA",
+ "CA",
+ "Nordics",
+ "MX",
+ "ES",
+ "TR",
+ "NL",
+ "AU",
+ "PL",
+ "TW",
+ "EU",
+ "LATAM",
+ "Asia",
+ "BE"
+]get_market1 field changedInput schema / properties / code / enumPrevious value: -[
- "US",
- "JP",
- "KR",
- "UK",
- "DE",
- "FR",
- "CN",
- "MENA",
- "IT",
- "CA"
-]New value: +[
+ "US",
+ "JP",
+ "KR",
+ "UK",
+ "DE",
+ "BR",
+ "FR",
+ "CN",
+ "MENA",
+ "IT",
+ "CA"
+]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",
- "BE"
-]New value: +[
+ "US",
+ "Global",
+ "JP",
+ "KR",
+ "Not market specific",
+ "UK",
+ "DE",
+ "BR",
+ "FR",
+ "CN",
+ "MENA",
+ "IT",
+ "SEA",
+ "CA",
+ "Nordics",
+ "IN",
+ "MX",
+ "ES",
+ "TR",
+ "NL",
+ "AU",
+ "PL",
+ "TW",
+ "EU",
+ "LATAM",
+ "Asia",
+ "BE"
+]search_sources5 fields changedInput schema / properties / cost / descriptionPrevious value: -"Recorded on 545 of 936 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 560 of 957 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",
- "Communities",
- "People"
-]New value: +[
+ "Press",
+ "Institutions",
+ "Media",
+ "Data",
+ "Communities",
+ "People"
+]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, BE 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, BR, FR, CN, MENA, IT, CA have full profiles behind them; SEA, Nordics, 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",
- "UK",
- "Not market specific",
- "DE",
- "FR",
- "CN",
- "MENA",
- "IT",
- "SEA",
- "CA",
- "Nordics",
- "BR",
- "IN",
- "MX",
- "ES",
- "TR",
- "NL",
- "AU",
- "PL",
- "TW",
- "EU",
- "LATAM",
- "Asia",
- "BE"
-]New value: +[
+ "US",
+ "Global",
+ "JP",
+ "KR",
+ "Not market specific",
+ "UK",
+ "DE",
+ "BR",
+ "FR",
+ "CN",
+ "MENA",
+ "IT",
+ "SEA",
+ "CA",
+ "Nordics",
+ "IN",
+ "MX",
+ "ES",
+ "TR",
+ "NL",
+ "AU",
+ "PL",
+ "TW",
+ "EU",
+ "LATAM",
+ "Asia",
+ "BE"
+]Input schema / properties / medium / enumPrevious 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"
-]New value: +[
+ "News outlet",
+ "Organisation",
+ "Forum or community",
+ "Person",
+ "Video channel",
+ "Data tool",
+ "Podcast",
+ "Book or paper",
+ "Company disclosure",
+ "Report or document",
+ "Newsletter",
+ "Research firm",
+ "Link list"
+]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",
- "BE"
-]New value: +[
+ "US",
+ "Global",
+ "JP",
+ "KR",
+ "Not market specific",
+ "UK",
+ "DE",
+ "BR",
+ "FR",
+ "CN",
+ "MENA",
+ "IT",
+ "SEA",
+ "CA",
+ "Nordics",
+ "IN",
+ "MX",
+ "ES",
+ "TR",
+ "NL",
+ "AU",
+ "PL",
+ "TW",
+ "EU",
+ "LATAM",
+ "Asia",
+ "BE"
+]list_trends5 fields changedInput schema / properties / groupAdded value: +{
+ "description": "One of the four groups inside h2: shifts that make room for h3, rules being rewritten, moves that prolong h1, and bets that stalled. Only h2 trends carry one.",
+ "enum": [
+ "makes-room",
+ "rewriting-rules",
+ "prolongs-h1",
+ "stalled-bets"
+ ],
+ "type": "string"
+}Input schema / properties / horizonAdded value: +{
+ "description": "h1 is the currently dominant system, losing its fit. h3 is the early working examples of what may replace it. h2 is the turbulent ground between them, sorted into four groups. perennial is the pressures every horizon has to answer.",
+ "enum": [
+ "h1",
+ "h2",
+ "h3",
+ "perennial"
+ ],
+ "type": "string"
+}Input schema / properties / limit / descriptionPrevious value: -"Rows per page, default 14, at most 38 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 and at most 14 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 / query / descriptionPrevious value: -"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."New value: +"Free text, matched against the name, what it is, why it matters, where to follow it, its category, its horizon label and line, 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."Input schema / properties / slug / descriptionPrevious value: -"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."New value: +"One trend by its permanent slug, as a list returns it. Comes back with its claims, and with its further reading unless include_further_reading says otherwise. The other filters are ignored when this is set."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",
- "BE"
-]New 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",
+ "BE"
+]search_sources3 fields changedInput schema / properties / cost / descriptionPrevious value: -"Recorded on 540 of 931 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 545 of 936 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",
- "Dutch",
- "Polish",
- "Traditional Chinese",
- "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",
+ "Multilingual",
+ "Bahasa Indonesia",
+ "Swedish",
+ "Vietnamese",
+ "Finnish",
+ "Danish",
+ "Norwegian",
+ "Thai",
+ "Hindi",
+ "Indonesian",
+ "Malay"
+]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",
- "BE"
-]New 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",
+ "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",
- "BE"
-]New 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",
+ "BE"
+]search_sources1 field changedInput schema / properties / cost / descriptionPrevious value: -"Recorded on 535 of 925 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 540 of 931 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_sources1 field changedInput schema / properties / cost / descriptionPrevious value: -"Recorded on 534 of 924 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 535 of 925 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_sources1 field changedInput schema / properties / cost / descriptionPrevious 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."New value: +"Recorded on 534 of 924 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_trends2 fields changedInput schema / properties / limit / descriptionPrevious 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."New value: +"Rows per page, default 14, at most 38 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",
- "Perennial",
- "Emerging",
- "Receding"
-]New value: +[
+ "Dominant",
+ "Emerging",
+ "Perennial",
+ "Receding"
+]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 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.
Sourced game design precedents: where a mechanic came from, why designers chose it, who reused it.
Add one secure layer between your agents and this server.
