Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

trustpilot_category_search

Search Trustpilot categories by keyword to retrieve matching category IDs and display names, with optional size, country, and locale filters.

Instructions

Search Trustpilot categories. Searches Trustpilot categories for the required q. size sets the maximum number of categories (default 20, from 1 to 100), country is a two-letter code (default US) and locale uses ll-CC format (default en-US). Each category has its category_id, display_name and top_level_category_id.

Input Schema

NameRequiredDescriptionDefault
qYesSearch query
sizeNoMaximum number of categories; defaults to 20
localeNoLocale in ll-CC format; defaults to en-US
countryNoTwo-letter country code; defaults to US

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses defaults (size 20, country US, locale en-US), the 1-100 size range, and the returned category fields, but says nothing about read-only safety, result ordering, pagination, or failure behavior for an unpaginated search.

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?

Three front-loaded sentences that move from action to parameters to return shape, with no filler. It is slightly repetitive in re-using 'categories' and 'Search Trustpilot categories' twice, but overall tight.

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 compensates by naming the returned fields (category_id, display_name, top_level_category_id) and covering all four parameters with defaults and formats. Only result ordering/pagination behavior is unaddressed.

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 coverage is 100%, so the baseline is 3; the description largely restates schema content (defaults, formats). It does add the 1-100 range for `size`, which the schema omits, but no other meaning beyond the schema.

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 states a specific verb+resource: 'Search Trustpilot categories', and the query-driven nature is clear. It does not, however, distinguish itself from siblings like trustpilot_categories or trustpilot_category, so an agent must infer the difference is 'search by text' vs 'enumerate/retrieve'.

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

Usage Guidelines3/5

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

Usage is implied by the required `q` parameter and the word 'search' – use it when you have a category name to look up. There is no explicit when-to-use vs. the listing/detail siblings and no exclusions, so guidance is only suggestive.

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

Deploy Server

Other Tools