Skip to main content
Glama
andrijdavid

Bazos-MCP

by andrijdavid
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Remote

Bazos-MCP

npm version npm downloads License: AGPL-3.0 Release Node.js

MCP server for interacting with Bazos.cz, Bazos.sk, Bazos.at, and Bazos.pl.

Features

  • Search ads across all sections on Czech, Slovak, Austrian, and Polish Bazos.

  • Retrieve detailed ad information.

  • Fetch user ratings by phone/email ID.

Related MCP server: olx-pik-toolkit

Installation

npm install -g @andrijdavid/bazos-mcp

Usage

Add to your MCP client configuration (e.g. Claude Desktop):

{
  "mcpServers": {
    "bazos": {
      "command": "npx",
      "args": ["-y", "@andrijdavid/bazos-mcp"]
    }
  }
}

Tools

search_ads

Search ads with filters.

Arguments:

  • domain: "cz", "sk", "at", or "pl"

  • section: Section code (e.g. AU for Auto)

  • query: Search query string

  • price_from: Minimum price

  • price_to: Maximum price

  • sort: date, price_asc, price_desc, distance

  • latitude / longitude: Required when sort is distance

  • offset: Pagination offset (multiples of 20)

  • limit: Page size (multiples of 20, max 200)

get_ad_detail

Get full details for an ad.

Arguments:

  • domain: "cz", "sk", "at", or "pl"

  • ad_id: The ad ID

get_user_ratings

Get user ratings.

Arguments:

  • domain: "cz", "sk", "at", or "pl"

  • phone: Phone ID

  • email: Email ID

  • offset: Pagination offset

  • limit: Page size

Sections

Code

Name

AU

Auto

DE

Deti

DU

Dum a Zahrada

EL

Elektro

FO

Foto

HU

Hudba

KN

Knihy

MO

Mobily

MT

Motorky

NA

Nabytek

OB

Obleceni

PC

PC

PR

Prace

RE

Reality

SL

Sluzby

SP

Sport

ST

Stroje

VS

Vstupenky

ZV

Zvirata

OS

Ostatni

Disclaimer

This project is not affiliated with or endorsed by Bazos.cz, Bazos.sk, Bazos.at, or Bazos.pl. The author is not responsible for any consequences arising from use of this software. The code is provided "as is", without warranty of any kind.

License

GNU AGPL-3.0. See LICENSE.

Available Tools

3 tools
get_ad_detailB

Get detailed information about a specific ad by its ID.

ParametersJSON Schema
NameRequiredDescriptionDefault
ad_idYesThe ad ID
domainYesDomain: cz, sk, at, or pl

TDQS

B3.3/5.0
Behavior3/5

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

No annotations are present, so the description carries full burden. It indicates a read operation without side effects, but does not mention authentication, rate limits, or that the tool is read-only. This is minimally sufficient for a simple getter.

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?

The description is a single sentence that is front-loaded and contains no unnecessary words. Every word is relevant.

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

Completeness3/5

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

With only 2 parameters and no output schema, the description is adequate but could be improved by specifying what 'detailed information' includes. Missing context about return structure or differences from sibling search_ads.

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?

The input schema has 100% description coverage, providing clear meanings for ad_id and domain. The description adds no extra value beyond the schema, therefore baseline score of 3 is appropriate.

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 clearly states 'Get detailed information about a specific ad by its ID.' The verb 'Get' and resource 'ad detail' are specific. It distinguishes from sibling tools like search_ads (searching) and get_user_ratings (ratings), though it could be more explicit about the scope.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. It does not mention when not to use it or that search_ads might be preferred for listing.

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

get_user_ratingsC

Get user ratings by phone ID and/or email ID.

ParametersJSON Schema
NameRequiredDescriptionDefault
emailNoEmail ID of the user
limitNoLimit for pagination. Default: 20.
phoneNoPhone ID of the user
domainYesDomain: cz, sk, at, or pl
offsetNoOffset for pagination. Default: 0.

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are present, so the description must disclose behavioral traits. It only states the basic function, omitting details like authentication, rate limits, data freshness, or that it returns a list of ratings. Schema covers pagination, but description adds no behavioral context.

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 description is a single concise sentence with no wasted words. However, it lacks structure (e.g., no mention of return format or example usage). It is efficient but could be slightly enhanced.

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

Completeness2/5

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

Given the absence of an output schema and annotations, the description should compensate by explaining what 'ratings' are, how domain affects results, and the behavior when multiple filters are combined. It fails to provide this context, leaving gaps for agent understanding.

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% with descriptions for all parameters. The description adds no extra semantic meaning beyond what the schema provides, only implying that phone and email are filter criteria. Baseline score of 3 is appropriate.

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 clearly states the verb 'Get' and the resource 'user ratings', and specifies filtering by phone ID and/or email ID. It is unambiguous and distinguishes from sibling tools which are about ads.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. The description merely states what it does, without any context on prerequisites, typical scenarios, or exclusions.

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

search_adsA

Search ads on Bazos.cz, Bazos.sk, Bazos.at, or Bazos.pl. Returns a list of ads matching the criteria.

ParametersJSON Schema
NameRequiredDescriptionDefault
sortNoSort type. Available: date, price_asc, price_desc, distance. For distance, provide latitude and longitude.
limitNoLimit for pagination. Default: 20. Must be a multiple of 20 up to 200.
queryNoSearch query string
domainYesDomain to search: cz, sk, at, or pl
offsetNoOffset for pagination. Default: 0. Must be a multiple of 20.
sectionNoSection code. Available: AU = Auto DE = Deti DU = Dum a Zahrada EL = Elektro FO = Foto HU = Hudba KN = Knihy MO = Mobily MT = Motorky NA = Nabytek OB = Obleceni PC = PC PR = Prace RE = Reality SL = Sluzby SP = Sport ST = Stroje VS = Vstupenky ZV = Zvirata OS = Ostatni
latitudeNoLatitude (required when sort is distance)
price_toNoMaximum price
longitudeNoLongitude (required when sort is distance)
price_fromNoMinimum price

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations provided, the description carries full burden but only states basic behavior (returns list of ads). It lacks details on pagination, sort behavior, error handling, or rate limits. Schema parameters hint at pagination and sorting but description does not clarify.

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?

Two concise sentences front-load the purpose and scope. No wasted words, efficient communication.

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

Completeness3/5

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

Given the parameter count (10) and no output schema or annotations, the description is minimal. It explains the general behavior but lacks details on return values, pagination behavior, and how to use parameters effectively. Adequate but incomplete for complex usage.

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% with descriptions for all 10 parameters. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

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 clearly states the tool searches ads on specific domains (Bazos.cz, .sk, .at, .pl) and returns a list of matching ads. It distinguishes itself from siblings (get_ad_detail, get_user_ratings) by focusing on search across multiple domains.

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?

The description implies usage for searching ads but provides no explicit guidance on when to use this tool versus alternatives like get_ad_detail or get_user_ratings. No exclusion criteria or context for choosing between tools.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.1.3
    • First observedget_ad_detail
    • First observedget_user_ratings
    • First observedsearch_ads
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: searching ads, getting ad details, and retrieving user ratings. There is no overlap or ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (search_ads, get_ad_detail, get_user_ratings), making them predictable and easy to understand.

Tool Count4/5

Three tools is slightly below average but reasonable for a focused read-only classified ads interface. The scope is appropriate, though a few more tools (e.g., list categories) could be added.

Completeness4/5

The toolset covers the core browsing workflow—search, detail view, and user ratings. Minor gaps exist (e.g., no explicit category listing or filtering), but the set is functional for typical use cases.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • olx-pik-toolkit

    mob-dev-org
    F
    license
    Not graded
    quality
    C
    maintenance
    MCP server for managing OLX.ba / PIK.ba shops, enabling listing management, category/location queries, sponsor operations, and image uploads via natural language.
    -

  • olx-mcp

    tkupcewicz
    A
    license
    Not graded
    quality
    D
    maintenance
    MCP server for OLX marketplace. Enables AI assistants to search listings, get offer details, track prices over time, and compare offers across OLX Poland and other supported countries.
    622
    4
    MIT

  • atcmarket-mcp

    pokys
    F
    license
    Not graded
    quality
    C
    maintenance
    Remote MCP server (Streamable HTTP) that reads and parses the public catalog website atcmarket.cz (AT Computers) to enable product search, category-filtered search, supported filter listing, product detail lookup, and cross-product comparison — without login or state.
    -