aukro-mcp

Browse Aukro Categories & Hierarchy

aukro_get_categories

Read-onlyIdempotent

Browse Aukro.cz marketplace categories to list root categories with live item counts, inspect category details and subcategories, or search the recursive category tree by keyword.

Instructions

Browse Aukro.cz marketplace categories. If categoryId is omitted, returns all 22 root categories with live active item counts. If categoryId is provided, returns category details, ancestor breadcrumbs, and direct subcategories with live item counts. Can also search category names across the entire recursive category tree using searchQuery.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "aukro_get_categories"
  }
}

Input Schema

Name	Required	Description
`categoryId`	No	Numeric category ID to inspect (omit to list root categories)
`maxResults`	No	Max matching categories to return when `searchQuery` is provided
`searchQuery`	No	Case-insensitive keyword to search categories (e.g. 'iphone', 'lego', 'mince'). Uses fast suggest + facet lookup (~120ms) by default.
`fullTreeScan`	No	When true with `searchQuery`, downloads and scans the entire 4,000+ node category tree (`/categories/aggregations/all`, ~8s cold / <3ms cached) instead of fast suggest+facet lookup

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 7, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavioral context beyond them: live active item counts, 22 root categories, ~120ms suggest lookup versus ~8s cold / <3ms cached full tree scan, and a 4,000+ node tree. It does not discuss failure modes or auth needs, but for a read-only browse tool the performance trade-off disclosure is the useful part.

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

Conciseness5/5

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

Three sentences, each covering one mode, with the default behavior (omitted categoryId) stated first. No filler or restatement of the tool name.

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?

No output schema exists, and the description compensates by describing what each mode returns (root categories with counts, ancestor breadcrumbs, direct subcategories, name matches). Combined with the latency notes, an agent knows enough to choose a mode and invoke it 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 baseline is 3, but the description adds cross-parameter meaning the schema only states in isolation: that categoryId toggles between root listing and detail-plus-subcategory mode, and that maxResults and fullTreeScan only take effect alongside searchQuery. That interaction is the main thing an agent needs to reason about.

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?

The description names a specific verb and resource (browse Aukro.cz marketplace categories) and enumerates the three distinct result shapes driven by which parameter is supplied. It is immediately distinguishable from siblings such as aukro_search_offers or aukro_get_category_attributes.

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 maps parameter combinations to modes: omit categoryId for roots, supply categoryId for details plus subcategories, use searchQuery to search the recursive tree. It does not explicitly name alternatives (e.g. when to prefer aukro_autocomplete for keyword lookup), so the routing is implied rather than stated.

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