How do I use willhaben-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@willhaben-mcp find 3-room apartments for sale in Graz under €400,000" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

willhaben-mcp

by aliildan

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Remote

willhaben-mcp

Search Austria's largest classifieds marketplace from any MCP client.

Browse real estate, cars, jobs, and second-hand listings on willhaben.at through Claude and other Model Context Protocol clients — with natural-language search, structured filters, and full listing details.

License: MIT Node ≥ 18 MCP Status: unofficial

IMPORTANT

Unofficial project — read this first. willhaben-mcp is not affiliated with, authorized by, or endorsed by willhaben. willhaben's Terms of Use and robots.txt prohibit automated access, and this tool performs automated access. It is provided for personal, non-commercial, educational use only, with no warranty, and you are solely responsible for how you use it and for complying with willhaben's terms and applicable law. See Legal & Responsible Use and DISCLAIMER.md. This is not legal advice.

Related MCP server: German Real Estate MCP Server

What you can do

🔍 Universal search across all four verticals from a single tool
🏠 Real estate — apartments & houses for sale/rent, filtered by price, rooms, area, location
🚗 Cars — used & new vehicles by make, model, price, year, mileage, fuel, transmission
💼 Jobs — listings by keyword and job type
🛍️ Marketplace — second-hand items by keyword, category, condition, price, location
📋 Listing details — full attributes, images, seller info, address, contact options
📍 Smart location — Austrian states resolved offline, plus live city / place / postal-code lookup
⚡ Zero configuration — no API keys, no tokens, no accounts
🛡️ Polite by design — one-request-at-a-time rate limiting and response caching built in

Coverage

Vertical	willhaben section	Approx. live inventory*
Marketplace	Marktplatz	~13,000,000 ads
Real estate	Immobilien	~110,000 listings
Cars & motor	Auto & Motor	~200,000 vehicles
Jobs	Jobs	~15,000 openings

*Approximate, fetched live from willhaben at the time of writing; the real numbers move daily.

Requirements

Node.js ≥ 18 (uses the built-in global fetch)
Any MCP-compatible client (Claude Desktop, Claude Code, etc.)

Quickstart

Run directly with npx (nothing to install):

npx willhaben-mcp

…or install globally:

npm install -g willhaben-mcp
willhaben-mcp

Register it with your MCP client

Add to your MCP config (e.g. claude_desktop_config.json):

{
  "mcpServers": {
    "willhaben": {
      "command": "npx",
      "args": ["-y", "willhaben-mcp"]
    }
  }
}

Or, if you've cloned the repo and built it locally (npm run build), point the client at the bundled dist/index.js. Replace <project-root> with the absolute path to your clone:

{
  "mcpServers": {
    "willhaben": {
      "command": "node",
      "args": ["<project-root>/dist/index.js"]
    }
  }
}

Then restart the client and ask something like "find 3-room apartments for sale in Graz under €400,000." The server speaks MCP over stdio — no ports, keys, or accounts.

Available tools

Tool	Purpose
`willhaben_search`	Universal search across any vertical
`willhaben_search_real_estate`	Apartments & houses (buy/rent) with property filters
`willhaben_search_cars`	Used/new cars with vehicle filters
`willhaben_search_jobs`	Job listings
`willhaben_search_marketplace`	Second-hand marketplace items
`willhaben_get_listing`	Full detail for a single listing by ID
`willhaben_get_categories`	Available category paths per vertical

Common to every search tool: rows (default 30, capped at 100) and page (default 1).

`willhaben_search`

vertical (required) — marketplace · real_estate · cars · jobs
keyword, category, location, price_from, price_to, sort

`willhaben_search_real_estate`

property_type — eigentumswohnung · haus · mietwohnung · grundstueck · …
action — buy · rent
location, price_from, price_to, rooms, area_from, area_to, sort

`willhaben_search_cars`

make, model (matched as keywords; a numeric willhaben make/model ID is used directly)
location, price_from, price_to, year_from, year_to, mileage_from, mileage_to
fuel_type — petrol · diesel · electric · hybrid_petrol · hybrid_diesel
transmission — manual · automatic
condition — used · new · year_old
sort

`willhaben_search_jobs`

keyword (include a place name here for location, e.g. "Software Wien")
job_type — Vollzeit · Teilzeit · …
sort

`willhaben_search_marketplace`

keyword, category, condition (neu/gebraucht/defekt), location, price_from, price_to, sort

`willhaben_get_listing`

id (required) — the listing/ad ID, e.g. 1370327604

`willhaben_get_categories`

vertical (required) — marketplace · real_estate · cars · jobs

Sort values

`sort`	Meaning	Verticals
`newest`	Most recent first	all
`relevance`	willhaben relevance	all
`price_asc` / `price_desc`	Price ↑ / ↓	real estate, cars, marketplace
`nearby`	Distance ↑	all
`area_asc` / `area_desc`	Living area ↑ / ↓	real estate
`mileage_asc` / `mileage_desc`	Mileage ↑ / ↓	cars
`year_asc` / `year_desc`	Registration year ↑ / ↓	cars

Sample output

A real-estate search returns a compact, scannable summary (truncated):

## Search Results: Eigentumswohnung
Found 333 listings (showing 3 of 3 per page, page 1)
Vertical: real_estate

1. Exklusives Wohnen in Graz-Eggenberg – moderne 2-Zimmer-Wohnung mit Loggia
   💰 € 185.000 | 📍 Graz, Eggenberg | 📐 63 m² | 🛏️ 2 rooms | 📊 € 2.936,51 /m²
   👤 Private | 🔗 https://www.willhaben.at/iad/immobilien/d/eigentumswohnung/...

2. …

willhaben_get_listing expands one ad into description highlights, full attribute list, image count, seller (private/dealer), address, and contact option.

Example prompts

Find 3-room apartments for sale in Graz under €400,000
Search used BMW under €15,000, automatic, registered after 2018
Show new iPhones on the marketplace in Vienna under €700
Get the full details for willhaben listing 1370327604

Bundled command & skill

The repo ships two optional Claude Code extras in .claude/ that build on the MCP tools:

/willhaben-search command — turns a one-line query ("2-room flat in Graz under 300k", "used BMW diesel automatic under 15k") into the right tool call and returns a clean comparison table with value metrics (€/m², €/km), locations, and links.
apartment-hunt skill — a multi-step real-estate workflow: search → score by value → dedupe → pull details on the top matches → ranked shortlist with rationale. Trigger it by asking to find/compare apartments or houses (e.g. "help me find a 2-bedroom flat in Vienna under €350k").

They're auto-discovered when you work inside this project. To use them globally, copy them into your user config:

cp .claude/commands/willhaben-search.md ~/.claude/commands/
cp -r .claude/skills/apartment-hunt ~/.claude/skills/

Both assume the MCP server is registered under the name willhaben (as in the config above). If you name it differently, update the allowed-tools prefix in the command.

Location filtering

Real-estate, car, and marketplace searches accept a location parameter resolved to a willhaben area in three tiers:

Input	Example	Resolution
Austrian state	`Wien`, `Steiermark`, `Tirol`	Instant, offline
City / place / postal code	`Graz`, `Innsbruck`, `6020`	Live via willhaben's area autocomplete
Numeric area ID	`900`	Passed through directly

Location filtering is not available for jobs (the jobs API does not support it). Put the place name in the job keyword instead (e.g. "Software Wien").

How it works

The server fetches public willhaben.at pages and reads the structured JSON that the site embeds in its __NEXT_DATA__ script tag — the same data the willhaben web app renders from. Jobs use the public publicapi.willhaben.at endpoint, and location names are resolved through willhaben's public area-autocomplete endpoint. No API keys, tokens, or reverse-engineered credentials are involved.

┌───────────────┐     ┌──────────────────┐     ┌────────────────────────┐
│   MCP client  │ ──▶ │   willhaben-mcp  │ ──▶ │  willhaben.at (public  │
│ (Claude, …)   │     │   (Node.js)      │     │  pages + public APIs)  │
└───────────────┘     └──────────────────┘     └────────────────────────┘
                            │  • __NEXT_DATA__ extraction (cheerio)
                            │  • publicapi.willhaben.at (jobs)
                            │  • /webapi/autocomplete/area (location)
                            │  • rate limit: 1 request/sec · 5-min response cache

Limitations & notes

Project / Bauträger ads (new developments) can appear in real-estate results even above your price_to, because willhaben surfaces them as teasers; the result count still reflects the filter, and per-unit ads respect it.
Car make/model are matched as free-text keywords unless you pass a numeric willhaben make/model ID. Brand names work well as keywords; exact model-ID filtering needs the ID.
Jobs don't support location filtering (the public jobs API ignores it) — fold the place into the keyword.
Dynamic location lookup (cities/postal codes) makes one extra network call to willhaben's area-autocomplete; Austrian state names resolve offline with no extra request.
Results are capped at 100 per page. This is a deliberate, polite default — don't work around it to bulk-harvest.
willhaben's page structure can change at any time; if extraction breaks, the tool returns a clear error rather than guessing.

Development

npm install          # install dependencies
npm run build        # bundle to dist/ (tsup)
npm run dev          # run from source (tsx)

npx tsx test/integration.test.ts   # smoke test across verticals
npx tsx test/filters.test.ts       # verify every filter end-to-end

src/
├── index.ts            # MCP server + tool definitions
├── api/
│   ├── scraper.ts      # __NEXT_DATA__ extraction, rate limit, cache
│   ├── search.ts       # search across real estate / cars / marketplace
│   ├── jobs.ts         # jobs via publicapi.willhaben.at
│   ├── detail.ts       # single-listing detail
│   ├── geo.ts          # location → areaId resolution (static + live)
│   └── types.ts        # willhaben response & tool I/O types
└── utils/
    ├── constants.ts    # verticals, URL patterns, sort codes, area IDs
    └── formatters.ts   # human-readable result formatting

Acknowledgements

A heartfelt thank-you to willhaben — Austria's #1 marketplace and one of the country's most-loved digital products. Every day, millions of people across Austria rely on willhaben to buy and sell, find a home, land a job, and give things a second life. This project exists only because willhaben built something genuinely useful, trusted, and woven into everyday Austrian life. 🇦🇹

All listings, data, content, and trademarks belong to willhaben and its users; this tool simply offers an individual a convenient way to browse the public site. We have deep respect for willhaben's work — and for their right to decide how their platform is accessed. If willhaben would prefer this project change or stop, please reach out (see DISCLAIMER.md) and we'll gladly cooperate.

Legal & Responsible Use

Please read the full DISCLAIMER.md. In short:

Not affiliated with willhaben. "willhaben" and related marks belong to their owners (willhaben internet service GmbH & Co KG) and are used only for identification.
willhaben prohibits automated access. Their robots.txt ("It is expressively forbidden to use spiders, search robots or other automatic methods to access willhaben.at") and their Terms of Use forbid crawler/robot copying of content and commercial reuse without prior consent. This tool performs automated access; a disclaimer does not make that access authorized.
You are responsible. By using this software you accept sole responsibility for complying with willhaben's Terms of Use and robots.txt, and with applicable law — which may include Austrian/EU unfair-competition (UWG), copyright and database rights, and GDPR (listings can contain personal data).
Personal & non-commercial only. Do not use it for commercial exploitation, bulk harvesting, redistributing willhaben data, or contacting advertisers at scale. For anything beyond personal use, seek written permission / an official feed from willhaben.
No warranty, no liability. Provided "AS IS" — see LICENSE.
Be polite. The built-in rate limit and cache exist to minimize load; don't remove or aggressively raise them.

This project is not legal advice. If in doubt, consult a qualified lawyer and/or contact willhaben.

License

MIT © Ali Ildan. The MIT license covers this software only; it grants no rights to willhaben's content, data, trademarks, or services.

Available Tools

7 tools

willhaben_get_categoriesA

Get available category paths for a willhaben.at vertical. Use these categories in search queries.

ParametersJSON Schema

Name	Required	Description	Default
`vertical`	Yes	Which vertical to get categories for

TDQS

A3.8/5.0

Behavior2/5

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

No annotations provided; description lacks behavioral details such as error handling, pagination, or output structure. Minimal transparency.

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-loaded with purpose and usage. No unnecessary words.

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?

Given the tool's simplicity (one parameter, no output schema), the description is adequate. Could mention output format, but not critical.

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 covers 100% of parameter description with enum and required status; description adds no extra semantic value beyond what the schema already provides.

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 retrieves category paths for a vertical and its use in search queries. It distinguishes from sibling search tools.

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?

The description implies usage before searching ('Use these categories in search queries'), but does not explicitly exclude other uses or list alternatives.

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

willhaben_get_listingA

Get full details for a specific willhaben.at listing by ID. Returns all attributes, images, seller info, contact details, and description.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	The willhaben listing/ad ID (e.g., '1370327604')

TDQS

A4.3/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It explicitly lists the returned data: attributes, images, seller info, contact details, and description. This covers the tool's behavior adequately.

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?

A single sentence that is front-loaded with the key action and resource, followed by the specific details returned. No extraneous words.

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?

Given the tool's simplicity (one parameter, no output schema, no nested objects), the description is complete. It explains what the tool does and what it returns.

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% for the single parameter 'id', which already has a description. The tool description adds minor context ('The willhaben listing/ad ID'), but does not significantly enhance understanding beyond the schema.

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 retrieves full details for a specific listing by ID, with a specific verb 'Get' and resource 'willhaben listing'. It distinguishes from sibling tools that focus on searching and categories.

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?

The description implies usage when a listing ID is available and full details are needed. It does not explicitly mention when not to use or provide alternatives, but the context and sibling names make it clear.

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

willhaben_searchA

Search willhaben.at across all verticals (marketplace, real estate, cars, jobs). Returns listing summaries with prices, locations, and key attributes.

ParametersJSON Schema

Name	Required	Description
`vertical`	Yes	Which vertical to search
`keyword`	No	Search term/keyword
`category`	No	Category path (e.g., 'eigentumswohnung/eigentumswohnung-angebote' for real estate)
`location`	No	Location: Austrian state, city, place, or postal code (e.g. 'Wien', 'Graz', 'Innsbruck', '6020'). Resolved to an area automatically. Not supported for jobs.
`price_from`	No	Minimum price
`price_to`	No	Maximum price
`sort`	No	Sort order: 'newest', 'nearby', 'price_asc', 'price_desc', 'relevance'
`rows`	No	Results per page (default: 30, max: 100)
`page`	No	Page number (default: 1)

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only describes return content (summaries with price/location/attributes) but omits pagination behavior, sorting behavior, required authentication, rate limits, or what happens if no results are found. This is insufficient for a search tool with 9 parameters.

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 sentences, no redundant information. The key purpose and output are front-loaded. Every sentence adds value.

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?

While the description covers the basic purpose and output, it lacks important contextual details like pagination, error handling, and search behavior nuances. Given the complexity (9 parameters, no output schema, no annotations), a more complete description is warranted.

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 schema has 100% description coverage for all parameters. The description adds no additional meaning beyond what the schema already provides, so a baseline of 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?

Clearly states the tool searches across all verticals (marketplace, real estate, cars, jobs) and returns listing summaries with key attributes. This distinguishes it from sibling tools that target specific verticals.

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?

The description 'across all verticals' implies a general search context, but it does not explicitly state when to use this tool versus the vertical-specific versions (e.g., willhaben_search_cars). No when-not or alternative guidance provided.

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

willhaben_search_carsA

Search willhaben.at car listings (used cars, new cars). Filter by make, model, price, year, mileage, fuel type, and transmission.

ParametersJSON Schema

Name	Required	Description
`make`	No	Car brand (e.g., 'BMW', 'Audi', 'Volkswagen'). Matched as a keyword unless a numeric willhaben make ID is given.
`model`	No	Car model (matched as a keyword)
`location`	No	Location: Austrian state, city, place, or postal code (e.g. 'Wien', 'Graz', '6020'). Resolved to an area automatically.
`price_from`	No	Minimum price
`price_to`	No	Maximum price
`year_from`	No	Minimum year of construction
`year_to`	No	Maximum year of construction
`mileage_from`	No	Minimum mileage in km
`mileage_to`	No	Maximum mileage in km
`fuel_type`	No	Fuel type: 'petrol', 'diesel', 'electric', 'hybrid_petrol', 'hybrid_diesel'
`transmission`	No	Transmission: 'manual' or 'automatic'
`condition`	No	Condition: 'used', 'new', 'year_old'
`sort`	No	Sort: 'newest', 'nearby', 'price_asc', 'price_desc', 'mileage_asc', 'mileage_desc', 'year_desc', 'year_asc', 'relevance'
`rows`	No	Results per page (default: 30)
`page`	No	Page number (default: 1)

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 must carry the full behavioral burden. It reveals the tool is for searching and filtering but omits traits like pagination (though present in schema), rate limits, authorization, or error behavior. It adds minimal context beyond the functional purpose.

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 sentence that is concise and front-loaded with the verb 'Search'. It wastes no words, though it could be slightly more structured (e.g., bullet points) for a tool with 15 parameters. Still, it is efficient.

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 15 parameters and no output schema or annotations, the description is too minimal. It does not explain the platform (willhaben.at), result format, error handling, or ordering of filters. A more complete description would cover these aspects for an AI agent to use effectively.

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 lists some filters but does not add new meaning beyond what is already in the schema's parameter descriptions. It summarizes a subset but does not enhance understanding significantly.

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 'Search willhaben.at car listings' with a specific verb and resource. It lists key filters like make, model, price, year, mileage, fuel type, and transmission, and the name includes 'cars', distinguishing it from sibling search tools for jobs, real estate, etc.

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 car searches but does not explicitly state when to use this tool versus siblings like willhaben_search or willhaben_search_marketplace. No when-not-to-use or alternative guidance is provided, leaving ambiguity for an AI agent.

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

willhaben_search_jobsC

Search willhaben.at job listings. Filter by keyword and job type.

ParametersJSON Schema

Name	Required	Description
`keyword`	No	Job title or keyword (also matches location names, e.g. 'Software Wien')
`job_type`	No	Job type: 'Vollzeit', 'Teilzeit', etc.
`sort`	No	Sort: 'newest' or 'nearby'
`rows`	No	Results per page (default: 30)
`page`	No	Page number (default: 1)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description should disclose behavioral details like side effects, authentication needs, or output structure. It only states it searches and filters, missing important transparency cues for a mutation-free tool.

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, front-loaded sentence that efficiently communicates the tool's core purpose. It is concise but not overly terse.

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?

The description lacks information about the output format or how results are returned, especially since no output schema is provided. It also does not clarify default behaviors or parameter interactions for a tool with five optional parameters.

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 already provides 100% coverage with descriptions for each parameter. The description adds no additional meaning beyond mentioning 'keyword and job type', so it meets baseline but does not elevate understanding.

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 tool searches job listings on willhaben.at and filters by keyword and job type. It is specific enough to distinguish it from sibling search tools for cars, real estate, etc.

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 the other search-related sibling tools (e.g., willhaben_search, willhaben_search_real_estate). The description does not mention exclusions or alternatives.

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

willhaben_search_marketplaceA

Search willhaben.at marketplace (Marktplatz) for second-hand items. Filter by keyword, category, condition, price, and location.

ParametersJSON Schema

Name	Required	Description
`keyword`	No	Search term/keyword
`category`	No	Category slug including the numeric ID (e.g., 'computer-software-5824', 'smartphones-telefonie-2691'). Use willhaben_get_categories to list valid slugs.
`condition`	No	Item condition: 'neu'/'new', 'gebraucht'/'used', or 'defekt'/'defective'
`location`	No	Location: Austrian state, city, place, or postal code (e.g. 'Wien', 'Graz', '6020')
`price_from`	No	Minimum price
`price_to`	No	Maximum price
`sort`	No	Sort: 'newest', 'price_asc', 'price_desc', 'relevance'
`rows`	No	Results per page (default: 30)
`page`	No	Page number (default: 1)

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as rate limits, authentication requirements, pagination behavior, or what happens on error or empty results. The description only states it performs a 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?

The description is a single sentence that efficiently conveys the tool's purpose and key filters. It is front-loaded and contains no unnecessary words, though it could be slightly more structured.

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?

Given the 9 parameters and no output schema, the description provides an adequate overview of what the tool does and the key filters. However, it lacks explanation of sorting, pagination, or location usage, though most are covered in the schema.

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 detailed parameter descriptions (e.g., category includes examples and references to willhaben_get_categories). The tool description adds no additional parameter meaning beyond what the schema provides.

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 it searches the willhaben marketplace for second-hand items, with specific filters (keyword, category, condition, price, location). This distinguishes it from sibling tools like willhaben_search_cars or willhaben_search_jobs, which target different categories.

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 this tool is for marketplace items, but does not explicitly state when to use it versus the generic willhaben_search or other specialized searches. No guidance on prerequisites or alternatives.

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

willhaben_search_real_estateA

Search willhaben.at real estate listings (apartments, houses for sale/rent). Filter by property type, price, rooms, area, and location.

ParametersJSON Schema

Name	Required	Description
`property_type`	No	Property type: 'eigentumswohnung' (apartment), 'haus' (house), 'mietwohnung' (rental), 'grundstueck' (land)
`action`	No	Buy or rent (default: buy)
`location`	No	Location: Austrian state, city, place, or postal code (e.g. 'Wien', 'Graz', '6020'). Resolved to an area automatically.
`price_from`	No	Minimum price
`price_to`	No	Maximum price
`rooms`	No	Number of rooms
`area_from`	No	Minimum living area in m²
`area_to`	No	Maximum living area in m²
`sort`	No	Sort: 'newest', 'nearby', 'price_asc', 'price_desc', 'area_asc', 'area_desc', 'relevance'
`rows`	No	Results per page (default: 30)
`page`	No	Page number (default: 1)

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must carry full burden. It only states the tool searches, with no disclosure of read-only nature, side effects, authentication needs, or rate limits. Minimal 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.

Conciseness5/5

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

One concise sentence that front-loads the action and resource, followed by filter details. No extraneous words, and the structure is efficient.

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 11 parameters, no output schema, and no annotations, the description is minimal. It covers the basic purpose and filter options but lacks information on return format, pagination, or how parameters interact. Adequate but with gaps.

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 description coverage is 100%, so baseline is 3. The description lists some filters (property type, price, rooms, area, location) but does not add meaning beyond what the schema already provides for all 11 parameters. No additional semantic detail.

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 it searches real estate listings on willhaben.at, specifying apartment and house types for sale/rent, and lists filters. Differentiates from siblings like willhaben_search_cars and willhaben_search_jobs by focusing on real estate.

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 real estate queries but does not explicitly state when to use this tool versus alternatives like willhaben_search or willhaben_search_cars. No when-not or exclusion criteria provided.

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. Dates show when Glama detected each change.

7 tool updatesv1.0.2Jun 9, 2026
- First observedwillhaben_get_categories
- First observedwillhaben_get_listing
- First observedwillhaben_search
- First observedwillhaben_search_cars
- First observedwillhaben_search_jobs
- First observedwillhaben_search_marketplace
- First observedwillhaben_search_real_estate

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Scored 2026-06-09 21:02 across 7 tools

Disambiguation5/5

Each tool targets a distinct purpose: categories, listing details, general search, and four vertical-specific searches (cars, jobs, marketplace, real estate). No overlap in functionality.

Naming Consistency5/5

All tools follow a consistent pattern: 'willhaben_' prefix followed by a clear verb_noun structure (get_categories, get_listing, search, search_cars, etc.).

Tool Count5/5

With 7 tools, the server is well-scoped for a classifieds platform, covering category retrieval, listing details, general search, and vertical-specific searches without being bloated or thin.

Completeness4/5

The tool set covers key operations for browsing and retrieving listings. Missing some potential helpers like make/model filters for cars, but the core search and detail retrieval is fully covered.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Defici Marketplace MCP Server A
com.defici
Search and browse global classifieds across 80 markets. No auth required for read-only access.
E-commerce & Retail Search
71
Partle A
xyz.rubenayla.partle
Search products in nearby stores. Agents can also list items for sale on a user's behalf.
E-commerce & Retail Location Services Search
2121
AssetLogOAuth
ai.assetlog
Search vehicles, real estate and jobs; manage your listings, alerts, enquiries and viewings.
E-commerce & Retail Search Real Estate
2
Buscador Google A
io.github.mcp-dir
Search Google straight from your AI agent. Web results, images, videos, news, products, scholarly ar
Search Browser Automation
181

Related MCP Servers

marktplaats-mcp
E-commerce & Retail Search
PonClick
A
license
Not graded
quality
F
maintenance
Enables AI assistants to search and view advertisements on Marktplaats.nl with extensive filtering options.
Updated 7 months ago (2026-02-11 09:36 UTC)
16
MIT
German Real Estate MCP Server
Real Estate Web Scraping
benthepythondev00
F
license
Not graded
quality
C
maintenance
Enables AI agents to search for German property listings (rent/buy) on immowelt.de with structured JSON output, no API key required.
Updated 3 months ago (2026-06-23 11:41 UTC)
-
marktplaats-mcp
E-commerce & Retail Search
jasp-nerd
A
license
A
quality
A
maintenance
Enables AI agents to search and monitor Dutch and Belgian classifieds (Marktplaats and 2dehands) for listings, seller profiles, and categories.
Updated 7 days ago (2026-09-02 09:25 UTC)
5
2
MIT
willhaben-mcp
E-commerce & Retail
Samxel
A
license
Not graded
quality
B
maintenance
Enables AI assistants to search willhaben.at marketplace listings and retrieve full ad details, using filters for category, condition, size, color, pattern, brand, and more.
Updated 19 hours ago (2026-09-08 08:58 UTC)
2
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/aliildan/willhaben-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

willhaben-mcp

Contents

What you can do

Coverage

Requirements

Quickstart

Register it with your MCP client

Available tools

willhaben_search

willhaben_search_real_estate

willhaben_search_cars

willhaben_search_jobs

willhaben_search_marketplace

willhaben_get_listing

willhaben_get_categories

Sort values

Sample output

Example prompts

Bundled command & skill

Location filtering

How it works

Limitations & notes

Development

Acknowledgements

Legal & Responsible Use

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`willhaben_search`

`willhaben_search_real_estate`

`willhaben_search_cars`

`willhaben_search_jobs`

`willhaben_search_marketplace`

`willhaben_get_listing`

`willhaben_get_categories`