Skip to main content
Glama
Sign In

gaisho

by co.gaisho
OverviewDiscussionsAdmin

get_category_overview

Read-only

Use this for category guidance and to ground the early factual reply; follow the installed daily shopping skill for URL exceptions and host-specific workflow. Independent product research may run concurrently; do not wait for that research to finish before giving the early reply. A worker given this result must reuse it. A product type as a whole (not particular products), computed live from current listings and offers: its key features first (what each means, its values from basic to best, how common each is and its typical price; dependent features under the feature they depend on), then its price levels (low end, median, high end) with the features typical at each, its kinds, its brand mix (national, marketplace, store brands, unbranded) and, per platform, its typical price and range, the brands it carries and who sells there (the platform itself, the brand, third-party sellers, independent shops, dropshippers), the same-product gap vs Amazon and resellers' gap vs the brand's own price; also feature notes worth knowing and common return reasons. Prices are approximate. No product counts. breakdown adds one table on request: platform, retailer, price_band, brand_tier, brand or a feature key (e.g. a feature x price_band), each cell with its typical price and rating. conditions limits all of it to the products meeting them; the result says which conditions were used and which were not. Use search_products for the products themselves.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "category": "<category>"
    },
    "name": "get_category_overview"
  }
}

Input Schema

NameRequiredDescriptionDefault
categoryYesProduct type id, plain words (e.g. 'air fryer'), or a product id / link (its category).
breakdownNoOptional. The table's one or two dimensions: platform, retailer, price_band, brand_tier, brand, or a feature key. Default: no table (the platform price ranges are always given).
conditionsNoOptional. Plain-language conditions the products must meet, as specs; not in category.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare this is a read-only, non-destructive, non-open-world operation, so the description does not need to repeat that. It adds useful behavioral context: results are computed live, prices are approximate, product counts are not included, and the conditions result reports which conditions were used. It does not describe rate limits or authentication requirements, but those are less critical for a read-only overview.

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

Conciseness2/5

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

The description is bloated and not front-loaded: it opens with workflow instructions about early replies and installed skills before stating what the tool actually does. The core content is a long run-on sentence listing many output dimensions, which is dense and harder to scan than a structured list. It contains useful information but is poorly organized and excessively verbose.

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 and a complex aggregate tool, the description needs to explain return content, and it does so extensively: key features, price levels, kinds, brand mix, platform details, gaps, feature notes, and return reasons. It also covers the optional breakdown table and conditions reporting. It could be clearer about the result format, but the content coverage is strong.

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 parameter documentation is already strong. The description adds meaning beyond the schema by explaining that conditions limit the entire result and that the result states which conditions were used and which were not. It also clarifies that breakdown produces a table with typical price and rating per cell, which is not fully captured in the schema description.

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 eventually states a specific purpose: an aggregate overview of a product type as a whole, not particular products, computed live from current listings and offers. It distinguishes this from 'search_products' for the products themselves. The purpose is clear, though it is buried behind workflow instructions about early replies and installed skills.

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 explicitly says to use this for category guidance and to ground the early factual reply, and it names 'search_products' as the alternative for individual products. It adds workflow context about concurrent independent research and not waiting for it. It lacks explicit when-not-to-use guidance beyond the one sibling, but the main alternative is covered.

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

All gaisho toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources