Skip to main content
Glama

Get market report

market_report
Read-only

Measures ONE market in depth before building or investing: the full observed price distribution by provider type and buyer tier, and the providers competing there. Use this when you need detailed market numbers, not a quick map. The market is the semantic neighbourhood of your query (nearest providers by text embedding, NO fixed category). Every field is MEASURED: the observed-pricing benchmark (median, mean, stdev, p25/p75, min–max range and n via the canonical pricing engine), how many providers are in the neighbourhood and how many are priced, and the top competing providers with observed price and relevance. Pass query (e.g. 'customer support chatbot'). Use find_market instead for a quick market map; research_capability for market + pricing + a ready shortlist in one call; search_providers to pick a product.

Input Schema

NameRequiredDescriptionDefault
limitNofull mode: members per page (1–150, default 50).
queryYesNatural-language capability or market, e.g. 'customer support chatbot' or 'ai phishing detection'.
offsetNofull mode: paging offset over members (default 0).
cohort_refNoOptional (1.17.0): reuse the exact set of comparable providers selected by an earlier price_benchmark / market_report / research_capability call (its cohort_ref), instead of re-selecting the market from new wording.
request_refNoOptional task reference (rq_ + 12 hex) from an earlier answer. Continues that task: its remembered facts (quantities, budget, requirements, benchmark selection) apply to this call, and the answer keeps the same request_ref.
response_modeNo'summary' (DEFAULT): neighbourhood counts, per-type/per-tier price cohorts and the top 12 providers. 'full' (1.17.0): EVERY member of the neighbourhood, paged with offset / limit, each with its price reading (plan, unit, currency, source, observed date).

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": true,
      +  "description": "JSON result; identical to the text content block.",
      +  "type": "object"
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / request_ref
      Added value: +{
      +  "description": "Optional task reference (rq_ + 12 hex) from an earlier answer. Continues that task: its remembered facts (quantities, budget, requirements, benchmark selection) apply to this call, and the answer keeps the same request_ref.",
      +  "type": "string"
      +}
  3. Changed4 schema fields changed
    • addedInput schema / properties / cohort_ref
      Added value: +{
      +  "description": "Optional (1.17.0): reuse the exact set of comparable providers selected by an earlier price_benchmark / market_report / research_capability call (its cohort_ref), instead of re-selecting the market from new wording.",
      +  "type": "string"
      +}
    • addedInput schema / properties / limit
      Added value: +{
      +  "description": "full mode: members per page (1–150, default 50).",
      +  "type": "number"
      +}
    • addedInput schema / properties / offset
      Added value: +{
      +  "description": "full mode: paging offset over members (default 0).",
      +  "type": "number"
      +}
    • changedInput schema / properties / response_mode / description
      Previous value: -"'summary' (DEFAULT) returns a compact block: neighbourhood counts, per-type/per-tier price cohorts and top providers. 'full' returns everything incl. the full member list."New value: +"'summary' (DEFAULT): neighbourhood counts, per-type/per-tier price cohorts and the top 12 providers. 'full' (1.17.0): EVERY member of the neighbourhood, paged with offset / limit, each with its price reading (plan, unit, currency, source, observed date)."
  4. Changed1 schema field changed
    • changedInput schema / properties / query / description
      Previous value: -"Natural-language capability or market, e.g. 'customer support chatbot' or 'ai phishing detection'. Alias: niche."New value: +"Natural-language capability or market, e.g. 'customer support chatbot' or 'ai phishing detection'."
  5. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly=true, openWorld=false, destructive=false, so safety is covered. The description adds meaningful context beyond that: all fields are MEASURED (no synthetic data), the market is derived by text embedding with no fixed category, and it clarifies what each response_mode contains.

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?

Front-loaded with purpose and routing before detail, and every clause carries information. Slightly verbose with repeated emphasis ('ONE', 'MEASURED' three times) but not padded.

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?

Output schema exists so return shape needn't be explained, and the description nonetheless covers modes, paging, cohort reuse, and request_ref continuation. Complete for an agent to call correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the bar is baseline 3. The description adds value by giving a concrete query example, clarifying the semantic-neighbourhood selection, and reinforcing the summary vs. full mode behavior beyond the schema text.

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

Purpose5/5

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

States a specific verb and resource ('Measures ONE market in depth') plus what it returns (price distribution by provider type/buyer tier, competing providers). Explicitly distinguishes from find_market, research_capability, and search_providers.

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

Usage Guidelines5/5

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

Gives the selecting condition ('when you need detailed market numbers, not a quick map') and names three alternatives with the use case for each. Routing is unambiguous.

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.

Resources