Skip to main content
Glama

Start Research

start_research

Starts a niche research from a short search phrase or a plain-language description of an app or service idea. A phrase is scanned directly (demand, sub-topics, competitors, signals); a description is first turned into real search queries, the best one is then scanned automatically. Demand is measured in one country and one language: country and language when given, otherwise the country and the language of the phrase (English: United States, Spanish: Spain, Portuguese: Brazil); write the phrase in the language people search in there. country and language of the answer tell how the numbers were measured. Returns the research id to poll with get_research. Counts as one research of the plan allowance, whether the data comes from the sources or from the shared cache.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
deepNoDeeper scan with more sub-topics and competitor checks. Available on plans that include it (Pro) and to administrators; counted as two researches.
textYesSearch phrase (e.g. "expense tracker") or a description of the idea in your own words, up to 400 characters.
localeNoLanguage of the conclusions and the final report. Defaults to the interface language of the account. Texts meant for the site and the stores are always written in the language of the market.
countryNoCountry to measure demand in, as an ISO 3166-1 alpha-2 code (BR, MX, PT, AR, CO, US, GB, DE, KZ, RU, BY…). App Store apps are looked up in the same country, the report writes prices, channels and copy for it, and sub-topics are measured there too. Omit it to use the country of the phrase's language. The phrase is measured in its own language when the country has it (Spanish in the United States), otherwise in the country's main language, so write it the way people search in that country.
languageNoLanguage the demand is measured in, when the guess from the phrase is not enough: French in Canada (CA + fr), Italian in Switzerland (CH + it), Spanish in the United States (US + es). It must be one of the languages of `country`; given without `country` it picks the main country of the language (pt: Brazil, nl: Netherlands). Omit it to use the language of the phrase.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / country / description
      Previous value: -"Country to measure demand in, as an ISO 3166-1 alpha-2 code (BR, MX, PT, AR, CO, US, GB, DE…). App Store apps are looked up in the same country, the report writes prices, channels and copy for it, and sub-topics are measured there too. Omit it to use the country of the phrase's language. The phrase is measured in its own language when the country has it (Spanish in the United States), otherwise in the country's main language, so write it the way people search in that country."New value: +"Country to measure demand in, as an ISO 3166-1 alpha-2 code (BR, MX, PT, AR, CO, US, GB, DE, KZ, RU, BY…). App Store apps are looked up in the same country, the report writes prices, channels and copy for it, and sub-topics are measured there too. Omit it to use the country of the phrase's language. The phrase is measured in its own language when the country has it (Spanish in the United States), otherwise in the country's main language, so write it the way people search in that country."
    • changedInput schema / properties / country / enum
      Previous value: -[
      -  "AE",
      -  "AL",
      -  "AM",
      -  "AO",
      -  "AR",
      -  "AT",
      -  "AU",
      -  "AZ",
      -  "BA",
      -  "BD",
      -  "BE",
      -  "BF",
      -  "BG",
      -  "BH",
      -  "BO",
      -  "BR",
      -  "CA",
      -  "CH",
      -  "CI",
      -  "CL",
      -  "CM",
      -  "CO",
      -  "CR",
      -  "CY",
      -  "CZ",
      -  "DE",
      -  "DK",
      -  "DZ",
      -  "EC",
      -  "EE",
      -  "EG",
      -  "ES",
      -  "FI",
      -  "FR",
      -  "GB",
      -  "GH",
      -  "GR",
      -  "GT",
      -  "HK",
      -  "HR",
      -  "HU",
      -  "ID",
      -  "IE",
      -  "IL",
      -  "IN",
      -  "IT",
      -  "JO",
      -  "JP",
      -  "KE",
      -  "KH",
      -  "KR",
      -  "KZ",
      -  "LK",
      -  "LT",
      -  "LV",
      -  "MA",
      -  "MC",
      -  "MD",
      -  "MK",
      -  "MM",
      -  "MT",
      -  "MX",
      -  "MY",
      -  "NG",
      -  "NI",
      -  "NL",
      -  "NO",
      -  "NZ",
      -  "PA",
      -  "PE",
      -  "PH",
      -  "PK",
      -  "PL",
      -  "PT",
      -  "PY",
      -  "RO",
      -  "RS",
      -  "SA",
      -  "SE",
      -  "SG",
      -  "SI",
      -  "SK",
      -  "SN",
      -  "SV",
      -  "TH",
      -  "TN",
      -  "TR",
      -  "TW",
      -  "UA",
      -  "US",
      -  "UY",
      -  "VE",
      -  "VN",
      -  "ZA"
      -]New value: +[
      +  "AE",
      +  "AL",
      +  "AM",
      +  "AO",
      +  "AR",
      +  "AT",
      +  "AU",
      +  "AZ",
      +  "BA",
      +  "BD",
      +  "BE",
      +  "BF",
      +  "BG",
      +  "BH",
      +  "BO",
      +  "BR",
      +  "BY",
      +  "CA",
      +  "CH",
      +  "CI",
      +  "CL",
      +  "CM",
      +  "CO",
      +  "CR",
      +  "CY",
      +  "CZ",
      +  "DE",
      +  "DK",
      +  "DZ",
      +  "EC",
      +  "EE",
      +  "EG",
      +  "ES",
      +  "FI",
      +  "FR",
      +  "GB",
      +  "GH",
      +  "GR",
      +  "GT",
      +  "HK",
      +  "HR",
      +  "HU",
      +  "ID",
      +  "IE",
      +  "IL",
      +  "IN",
      +  "IT",
      +  "JO",
      +  "JP",
      +  "KE",
      +  "KH",
      +  "KR",
      +  "KZ",
      +  "LK",
      +  "LT",
      +  "LV",
      +  "MA",
      +  "MC",
      +  "MD",
      +  "MK",
      +  "MM",
      +  "MT",
      +  "MX",
      +  "MY",
      +  "NG",
      +  "NI",
      +  "NL",
      +  "NO",
      +  "NZ",
      +  "PA",
      +  "PE",
      +  "PH",
      +  "PK",
      +  "PL",
      +  "PT",
      +  "PY",
      +  "RO",
      +  "RS",
      +  "RU",
      +  "SA",
      +  "SE",
      +  "SG",
      +  "SI",
      +  "SK",
      +  "SN",
      +  "SV",
      +  "TH",
      +  "TN",
      +  "TR",
      +  "TW",
      +  "UA",
      +  "US",
      +  "UY",
      +  "VE",
      +  "VN",
      +  "ZA"
      +]
    • changedInput schema / properties / language / enum
      Previous value: -[
      -  "ar",
      -  "az",
      -  "bg",
      -  "bn",
      -  "bs",
      -  "cs",
      -  "da",
      -  "de",
      -  "el",
      -  "en",
      -  "es",
      -  "et",
      -  "fi",
      -  "fr",
      -  "he",
      -  "hi",
      -  "hr",
      -  "hu",
      -  "hy",
      -  "id",
      -  "it",
      -  "ja",
      -  "ko",
      -  "lt",
      -  "lv",
      -  "mk",
      -  "ms",
      -  "nb",
      -  "nl",
      -  "pl",
      -  "pt",
      -  "ro",
      -  "ru",
      -  "sk",
      -  "sl",
      -  "sq",
      -  "sr",
      -  "sv",
      -  "th",
      -  "tl",
      -  "tr",
      -  "uk",
      -  "ur",
      -  "vi",
      -  "zh-CN",
      -  "zh-TW"
      -]New value: +[
      +  "ar",
      +  "az",
      +  "be",
      +  "bg",
      +  "bn",
      +  "bs",
      +  "cs",
      +  "da",
      +  "de",
      +  "el",
      +  "en",
      +  "es",
      +  "et",
      +  "fi",
      +  "fr",
      +  "he",
      +  "hi",
      +  "hr",
      +  "hu",
      +  "hy",
      +  "id",
      +  "it",
      +  "ja",
      +  "ko",
      +  "lt",
      +  "lv",
      +  "mk",
      +  "ms",
      +  "nb",
      +  "nl",
      +  "pl",
      +  "pt",
      +  "ro",
      +  "ru",
      +  "sk",
      +  "sl",
      +  "sq",
      +  "sr",
      +  "sv",
      +  "th",
      +  "tl",
      +  "tr",
      +  "uk",
      +  "ur",
      +  "vi",
      +  "zh-CN",
      +  "zh-TW"
      +]
  2. Changed1 schema field changed
    • addedInput schema / properties / language
      Added value: +{
      +  "description": "Language the demand is measured in, when the guess from the phrase is not enough: French in Canada (CA + fr), Italian in Switzerland (CH + it), Spanish in the United States (US + es). It must be one of the languages of `country`; given without `country` it picks the main country of the language (pt: Brazil, nl: Netherlands). Omit it to use the language of the phrase.",
      +  "enum": [
      +    "ar",
      +    "az",
      +    "bg",
      +    "bn",
      +    "bs",
      +    "cs",
      +    "da",
      +    "de",
      +    "el",
      +    "en",
      +    "es",
      +    "et",
      +    "fi",
      +    "fr",
      +    "he",
      +    "hi",
      +    "hr",
      +    "hu",
      +    "hy",
      +    "id",
      +    "it",
      +    "ja",
      +    "ko",
      +    "lt",
      +    "lv",
      +    "mk",
      +    "ms",
      +    "nb",
      +    "nl",
      +    "pl",
      +    "pt",
      +    "ro",
      +    "ru",
      +    "sk",
      +    "sl",
      +    "sq",
      +    "sr",
      +    "sv",
      +    "th",
      +    "tl",
      +    "tr",
      +    "uk",
      +    "ur",
      +    "vi",
      +    "zh-CN",
      +    "zh-TW"
      +  ],
      +  "type": "string"
      +}
  3. Changed1 schema field changed
    • addedInput schema / properties / country
      Added value: +{
      +  "description": "Country to measure demand in, as an ISO 3166-1 alpha-2 code (BR, MX, PT, AR, CO, US, GB, DE…). App Store apps are looked up in the same country, the report writes prices, channels and copy for it, and sub-topics are measured there too. Omit it to use the country of the phrase's language. The phrase is measured in its own language when the country has it (Spanish in the United States), otherwise in the country's main language, so write it the way people search in that country.",
      +  "enum": [
      +    "AE",
      +    "AL",
      +    "AM",
      +    "AO",
      +    "AR",
      +    "AT",
      +    "AU",
      +    "AZ",
      +    "BA",
      +    "BD",
      +    "BE",
      +    "BF",
      +    "BG",
      +    "BH",
      +    "BO",
      +    "BR",
      +    "CA",
      +    "CH",
      +    "CI",
      +    "CL",
      +    "CM",
      +    "CO",
      +    "CR",
      +    "CY",
      +    "CZ",
      +    "DE",
      +    "DK",
      +    "DZ",
      +    "EC",
      +    "EE",
      +    "EG",
      +    "ES",
      +    "FI",
      +    "FR",
      +    "GB",
      +    "GH",
      +    "GR",
      +    "GT",
      +    "HK",
      +    "HR",
      +    "HU",
      +    "ID",
      +    "IE",
      +    "IL",
      +    "IN",
      +    "IT",
      +    "JO",
      +    "JP",
      +    "KE",
      +    "KH",
      +    "KR",
      +    "KZ",
      +    "LK",
      +    "LT",
      +    "LV",
      +    "MA",
      +    "MC",
      +    "MD",
      +    "MK",
      +    "MM",
      +    "MT",
      +    "MX",
      +    "MY",
      +    "NG",
      +    "NI",
      +    "NL",
      +    "NO",
      +    "NZ",
      +    "PA",
      +    "PE",
      +    "PH",
      +    "PK",
      +    "PL",
      +    "PT",
      +    "PY",
      +    "RO",
      +    "RS",
      +    "SA",
      +    "SE",
      +    "SG",
      +    "SI",
      +    "SK",
      +    "SN",
      +    "SV",
      +    "TH",
      +    "TN",
      +    "TR",
      +    "TW",
      +    "UA",
      +    "US",
      +    "UY",
      +    "VE",
      +    "VN",
      +    "ZA"
      +  ],
      +  "type": "string"
      +}
  4. First observed

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does add real behavioral context: it discloses billing (counts as one research, from sources or shared cache; deep counts as two), availability gating (Pro/admin), and how country/language are resolved and reported. It omits auth requirements and latency/rate details, but the cost and defaulting behavior is unusually well disclosed.

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

Conciseness4/5

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

The description is front-loaded with the core action and stays in a single dense paragraph with no filler sentences. It is somewhat long and overlaps with schema documentation, but every clause carries information.

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

Completeness5/5

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

For a tool with no output schema, the description supplies the missing return contract ("returns the research id to poll with get_research"), plus billing, defaulting, and language-resolution rules. Nothing an agent needs to invoke it correctly appears to be missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents the country/language/deep semantics in detail. The description largely restates the same defaulting logic (English: US, Spanish: Spain, Portuguese: Brazil) and adds the useful note that the answer's country/language reveal how numbers were measured, but contributes little beyond the schema. Baseline 3 applies.

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

Purpose4/5

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

The description states a specific verb+resource ("Starts a niche research") and explains the two input modes: a phrase is scanned directly, a description is converted to queries first. It names get_research as the polling target, but does not differentiate from other siblings like compare_research or follow_niche.

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

Usage Guidelines4/5

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

It clearly explains the conditions under which each input type is treated (phrase scanned directly vs. description converted and best query scanned) and what to do next (poll with get_research). No explicit when-not or comparison against sibling tools, but the usage context is clear.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.