marktplaats-mcp

Overview Schema Source Related Servers Discussions Admin

search_listings

Search Marktplaats.nl listings by keyword, category, price, distance, condition, and seller type to find items that match your criteria.

Instructions

Search for listings on Marktplaats.nl.

Args: query: Search query text (required if no category specified) category: Main category name (e.g., "computers en software", "fietsen en brommers") subcategory: Subcategory name (e.g., "laptops", "elektrische fietsen") zip_code: Dutch postal code for distance calculations (e.g., "1016LV"). Required for distance filtering! distance_km: Maximum distance in kilometers (default: 1000). Only works with zip_code. price_from: Minimum price in euros price_to: Maximum price in euros condition: Item condition: "new", "as_good_as_new", "used", "refurbished", "not_working" seller_type: Filter by seller type: "business" (zakelijk, for VAT invoices) or "private" (particulier) sort_by: Sort method: "date", "price", "optimized", "location" sort_order: Sort order: "asc" or "desc" limit: Number of results (1-100, default: 10) offset: Pagination offset offered_since_days: Only show items posted within the last X days attribute_ids: List of attribute filter IDs (use get_category_filters to find these) extract_specs: Try to extract hardware specs (RAM, storage, CPU) from descriptions (for laptops/tablets) compact: Return minimal response format (~75% smaller). Omits description, image, links. Use get_listing_details(id) for full info. Seller: B=business, P=private. Condition: N=new, Z=as good as new, G=used, R=refurbished, D=defect.

Returns: Dictionary with total_count, returned_count, and list of listings

Input Schema

TableJSON Schema

Name	Required	Default
`limit`	No
`query`	No
`offset`	No
`compact`	No
`sort_by`	No	optimized
`category`	No
`price_to`	No
`zip_code`	No
`condition`	No
`price_from`	No
`sort_order`	No	asc
`distance_km`	No
`seller_type`	No
`subcategory`	No
`attribute_ids`	No
`extract_specs`	No
`offered_since_days`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 16, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses compact mode's ~75% smaller payload and exactly what it omits (description, image, links), plus the coded abbreviations (B/P seller, N/Z/G/R/D condition) an agent must decode. It omits any note on rate limits or authentication, which keeps it short of 5.

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 one-line purpose is front-loaded and each Args entry is a single tight line. The compact-mode paragraph is dense but every sentence adds decoding value, so there is little waste.

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?

For a 17-parameter search tool with an output schema, the description documents all inputs plus the compact return format and cross-references to sibling tools. Return values are only briefly summarized, but the output schema covers that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry all 17 parameters — and it does, defining each with examples, defaults (limit 1-100 default 10, distance_km default 1000), allowed enum-like values for condition/seller_type/sort_by/sort_order, and dependency constraints. This fully compensates for the bare 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?

States a specific verb (search) and resource (listings) scoped to Marktplaats.nl, making the domain unambiguous. It does not explicitly distinguish itself from sibling get_listing_details at the top level, though it does reference that sibling later in the compact note.

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 conditional guidance inline: query is 'required if no category specified', distance_km 'Only works with zip_code', and attribute_ids points to get_category_filters. It also routes to get_listing_details for full info when using compact mode. No explicit when-not-to-use-this-tool statement, but the conditions are clear.

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

Deploy Server