Skip to main content
Glama

Find a market

find_market
Read-only

Maps a task to its market: who competes there, how many are priced, and the price level per buyer tier. Use this when someone asks who competes in a space or what a kind of product costs, e.g. 'tools that monitor competitor pricing'. Returns the market label (nearest providers by meaning, no fixed categories), provider and priced counts, the nearest providers with observed prices, and pricing_by_tier (median, p25/p75, range and n per buyer tier). When nothing is close it returns no_match or thin_coverage and withholds pricing rather than invent a market. Use market_report instead for the full measured breakdown; research_capability for market plus shortlist in one call; price_benchmark to judge a specific price.

Input Schema

NameRequiredDescriptionDefault
taskYesREQUIRED. A natural-language task, capability or service in plain words, e.g. 'reconcile supplier invoices'. Call as {"task": "…"}; an empty call returns status needs_input with an example and searches nothing.
queryNoAlias for task (back-compat only) — prefer task

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. Changed4 schema fields changed
    • removedInput schema / anyOf
      Removed value: -[
      -  {
      -    "required": [
      -      "task"
      -    ]
      -  },
      -  {
      -    "required": [
      -      "query"
      -    ]
      -  }
      -]
    • changedInput schema / properties / query / description
      Previous value: -"Alias for task (back-compat) — a natural-language task, capability or service"New value: +"Alias for task (back-compat only) — prefer task"
    • changedInput schema / properties / task / description
      Previous value: -"A natural-language task, capability or service, e.g. 'reconcile supplier invoices'"New value: +"REQUIRED. A natural-language task, capability or service in plain words, e.g. 'reconcile supplier invoices'. Call as {\"task\": \"…\"}; an empty call returns status needs_input with an example and searches nothing."
    • addedInput schema / required
      Added value: +[
      +  "task"
      +]
  3. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already cover the read-only, non-open-world, non-destructive profile, so the description's value is the extra behavior it discloses: matching is semantic with no fixed categories, and when coverage is weak it returns no_match or thin_coverage and withholds pricing rather than fabricating a market. That negative-path behavior is exactly what an agent needs to interpret an empty-looking result.

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 trigger before the return-value detail, and every sentence is load-bearing. The long enumeration of return fields is slightly redundant given a declared output schema, which is the only real trimming opportunity.

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

Completeness4/5

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

Covers trigger conditions, semantic matching model, fallback states, and sibling routing, which is ample for a two-parameter read tool. The extended return-value narration overlaps with the existing output schema, so it is complete with a little duplication rather than a gap.

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%, and the schema already documents both the required task string, the empty-call behavior, and the query back-compat alias. The description adds only an illustrative example ('tools that monitor competitor pricing'), which the schema already supplies in kind. Baseline 3 applies when the schema carries the parameter burden.

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 ('Maps a task to its market') and immediately enumerates the scope: who competes, how many are priced, price level per buyer tier. The description of the semantic nearest-provider matching ('nearest providers by meaning, no fixed categories') distinguishes it clearly from category-browsing siblings like search_providers or market_report.

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 an explicit trigger ('when someone asks who competes in a space or what a kind of product costs') with a concrete example query. It then routes to three named alternatives with the condition that selects each: market_report for the full measured breakdown, research_capability for market plus shortlist, price_benchmark to judge a specific price.

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