Skip to main content
Glama

agentery

by com.agentery
OverviewDiscussionsAdmin

Get market report

market_report
Read-only

Deep-dive ONE market before building or investing — the market is the semantic neighbourhood of your natural-language query (nearest providers by text embedding, NO fixed category). Every field is MEASURED: the observed-pricing benchmark separated by provider type and buyer tier (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 providers already competing there with their observed price and relevance. Pass query (a natural-language capability or market, e.g. 'customer support chatbot'). For market + pricing + a ready shortlist in one call, use research_capability.

Input Schema

TableJSON 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).

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
+}
  2. 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)."
  3. 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'."
  4. Added

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare read-only, closed-world and non-destructive, so the safety profile is covered. The description adds substantial behavioral context: fields are 'MEASURED' via a canonical pricing engine, with the exact statistics (median, mean, stdev, p25/p75, min–max, n), provider counts, and top competitors. It does not cover rate limits or auth, but the computational semantics are 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 purpose and the definition of 'market' are front-loaded, and the alternative tool is named last. The middle sentence is a long run-on enumerating every return field, but each clause conveys a distinct measured dimension rather than filler, so the density is mostly earned.

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?

With no output schema, the description must explain what comes back — and it does, listing the pricing benchmark fields, neighbourhood counts, and top competitors. Combined with the read-only annotations and fully documented schema, an agent has nearly everything needed to call it correctly; pagination behavior in full mode is the only thin spot.

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 all six parameters including the response_mode enum and cohort_ref reuse semantics. The description reinforces query format ('customer support chatbot') and the summary-vs-full distinction, but adds little syntax or semantics the schema does not already carry. Baseline 3 applies when the schema does the heavy lifting.

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 ('Deep-dive ONE market') and immediately defines the key concept — the market as the semantic neighbourhood of a natural-language query with NO fixed category. It differentiates itself from a category-based lookup and names the sibling (research_capability) that bundles market + pricing + shortlist, so an agent can route without opening a schema.

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?

Gives clear context ('before building or investing') and an explicit alternative: 'For market + pricing + a ready shortlist in one call, use research_capability.' The cohort_ref/request_ref descriptions also imply a continuation workflow with price_benchmark. It stops short of a full when-not-to-use statement, but the routing guidance is concrete.

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

All agentery toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources