German foreclosure auctions (Zwangsversteigerungen): search, details, AI analysis, statistics.
Scored across 6 tools
Each tool has a clearly distinct purpose: search auctions, retrieve one auction, get filter options, get statistics, list courts, and list states. There is no meaningful overlap between tools, and an agent can easily select the right one based on the task.
All tool names follow a consistent snake_case verb_noun pattern using get_, list_, or search_ prefixes appropriate to their operation. The convention is predictable and readable throughout the set.
Six tools is well-scoped for a read-only foreclosure-auction browsing server. Each tool covers a distinct capability, and none feels redundant or token.
The surface covers search, detail retrieval, filtering metadata, aggregate statistics, and geographic hierarchy, which is strong for a read-only domain. Minor gaps exist, such as no dedicated tool for retrieving full POI lists (noted as available only via REST API) or deeper court-level detail, but core workflows are supported.
Get full details for a specific auction by its UUID.
Returns complete data including AI analysis, appraisal (Gutachten),
images, files, geocoding data, and a POI (points of interest) summary:
per category the total, the counts within 500/1000/2500/5000 m and the
3 nearest places. The full POI lists are on the REST API (pois_full_list).
Args:
auction_id: The auction UUID (from search results)
| Name | Required | Description | Default |
|---|---|---|---|
| auction_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it explains the rich payload (AI analysis, appraisal, images, files, geocoding, POI summary) and notes that full POI lists are only on the REST API. It does not explicitly state read-only behavior, permissions, or error handling, but the 'Get' framing and return details provide substantial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The first sentence front-loads the core action and scope, followed by useful return details and a short Args section. It is appropriately sized and every part contributes to correct invocation or understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter detail-fetch tool with an output schema, the description is largely complete: it explains the parameter source, the returned data categories, and a POI limitation. Minor gaps remain around failure modes or permissions, which keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for the lone parameter. It does by specifying that auction_id is a UUID and where it comes from ('from search results'), which adds meaningful semantics beyond the schema title 'Auction Id.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Get full details for a specific auction by its UUID.' It clearly distinguishes this detail lookup from sibling search/listing tools such as search_auctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context by noting the UUID comes 'from search results,' implying this follows a search. It does not explicitly name alternatives or state when not to use it, so it falls just short of the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get available filter values for searching auctions.
Returns lists of valid property types and auction types with counts for each.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden; it does disclose that the response contains lists plus per-item counts, which is useful. It does not state that it is a side-effect-free lookup or mention any auth or rate-limit characteristics, leaving the safety profile to inference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the purpose followed by the return contents, with no filler. Minor redundancy between 'filter values' and the enumeration of lists, but nothing that wastes an agent's attention.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter lookup with an output schema, the description covers purpose and return shape adequately. The one missing piece is a pointer that the returned values feed search_auctions' filters, which would close the loop with the sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so baseline is 4; there is nothing for the description to disambiguate. The stated return structure is complementary rather than compensatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb and resource ('Get available filter values') and specifies the return contents (property types and auction types with counts). It is clearly a distinct lookup tool versus search_auctions or get_market_statistics, though it does not explicitly say so.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for searching auctions' implies this should be called to discover valid filter values before running a search, but it never names search_auctions as the consumer or states any when-not conditions. Usage 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.
Get aggregated market statistics for German foreclosure auctions.
Returns total active auctions, distribution by state, average price, and property type breakdown, limited to the states this key can read.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral-disclosure burden. It usefully states the aggregated return categories and that results are limited to states the key can read, which is important permission-scoping context. It does not describe freshness, caching, rate limits, or error behavior, so it remains only moderately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, front-loaded with the core action, and then lists the returned aggregates. Every sentence contributes useful information with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description need not fully explain return structure. The description still summarizes the returned metrics and notes the key-based state restriction, which is sufficient for a parameterless read tool. Minor usage-guidance gaps remain, but the core context is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics burden and the baseline is 4. The schema is empty and consistent with a parameterless aggregate endpoint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: retrieving aggregated market statistics for German foreclosure auctions. It also enumerates the metrics returned, making the tool clearly distinct from auction lookup and search tools. However, it does not explicitly name sibling tools or contrast itself with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied: aggregated statistics rather than individual auction retrieval. An agent can infer this is for market overview, but the description does not explicitly say when to choose it over search_auctions or get_auction, nor does it state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all courts (Amtsgerichte) in a specific German state with auction counts.
Args:
land: State abbreviation (e.g. 'by' for Bayern, 'nw' for Nordrhein-Westfalen,
'he' for Hessen, 'rp' for Rheinland-Pfalz, 'ni' for Niedersachsen,
'be' for Berlin, 'br' for Brandenburg, 'sn' for Sachsen,
'st' for Sachsen-Anhalt, 'th' for Thüringen, 'sh' for Schleswig-Holstein,
'hh' for Hamburg, 'hb' for Bremen, 'sl' for Saarland, 'mv' for Mecklenburg-Vorpommern)
| Name | Required | Description | Default |
|---|---|---|---|
| land | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It does add real value by revealing the return payload includes auction counts, and the 'List' verb signals a read-only operation. It does not state error behavior for an invalid or unknown state abbreviation, nor whether counts are current or cached.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The summary sentence is front-loaded and the Args block follows in the conventional place. The 16-item abbreviation list is long but each entry earns its place given the empty schema; only the parenthetical glosses on the first five states are mild redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a single-parameter read tool with an output schema, so return-value documentation is correctly omitted. The one thing an agent could get wrong — the state identifier format — is fully specified, leaving no material gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate entirely and it does: it enumerates every accepted abbreviation (by, nw, he, rp, ni, be, br, sn, st, th, sh, hh, hb, sl, mv) with a worked example for the first few. An agent can construct a valid call without guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource+scope: 'List all courts (Amtsgerichte) in a specific German state with auction counts.' It distinguishes itself from list_federal_states by operating one level deeper (courts within a state), though it does not explicitly name that sibling or the parent-child relationship between the two.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the agent can infer this is the drill-down after picking a state, but the description never says 'call list_federal_states first to obtain valid abbreviations' nor when to prefer search_auctions instead. With five siblings in the namespace, an explicit routing sentence is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the German federal states (Bundesländer) this key can read, with the number of active auctions in each.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose two non-obvious traits: results are permission-scoped to the caller's key, and each entry is enriched with a live active-auction count (so the numbers are time-dependent). It omits ordering, empty-result behavior, and whether counts are cached, which keeps it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with zero filler, front-loading the resource and the access scope before the return detail. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool with an output schema, the description supplies everything needed: what is listed, the access scoping, and the enrichment per entry. Return-shape detail is correctly delegated to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4; there is nothing for the description to clarify beyond confirming the call is argument-free. No param-level information is needed or missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (list) and resource (German federal states / Bundesländer) plus the exact payload of each entry (active auction count). The resource is unambiguous against siblings like list_courts_in_state, get_market_statistics, and search_auctions, so an agent can pick it without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'this key can read' implies this is a discovery/scoping call to run before querying auctions, but the description never says when to prefer it over get_filter_options, which plausibly also enumerates states. No explicit when-not or prerequisite guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search German foreclosure auctions with filters.
Args:
land: German state abbreviation (e.g. 'by' for Bayern, 'nw' for Nordrhein-Westfalen).
A sandbox key only accepts 'st' (Sachsen-Anhalt).
court: Court name (e.g. 'München', 'Berlin')
object_type: Property type (apartment, detached_house, multi_family_house, etc.)
city: City name
plz: Postal code
min_price: Minimum Verkehrswert in EUR
max_price: Maximum Verkehrswert in EUR
min_rooms: Minimum number of rooms
max_rooms: Maximum number of rooms
min_area: Minimum living area in m²
max_area: Maximum living area in m²
auction_date_from: Start date (YYYY-MM-DD)
auction_date_to: End date (YYYY-MM-DD)
q: Full-text search query
lat: Latitude for radius search
lng: Longitude for radius search
radius_km: Search radius in km (1-500)
sort: Sort by: auction_date, price, distance, created_at
order: Sort order: asc, desc
page: Page number (default 1)
per_page: Results per page (default 10, max 50)
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| lat | No | ||
| lng | No | ||
| plz | No | ||
| city | No | ||
| land | No | ||
| page | No | ||
| sort | No | auction_date | |
| court | No | ||
| order | No | asc | |
| max_area | No | ||
| min_area | No | ||
| per_page | No | ||
| max_price | No | ||
| max_rooms | No | ||
| min_price | No | ||
| min_rooms | No | ||
| radius_km | No | ||
| object_type | No | ||
| auction_date_to | No | ||
| auction_date_from | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose one useful operational constraint (a sandbox key only accepts 'st'), but it says nothing about authentication requirements beyond that, rate limits, what happens when lat/lng are supplied without radius_km, or any response behavior. The one disclosed constraint prevents a lower score, but the disclosure is far from complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first line, and each parameter line earns its place by clarifying a field the schema leaves undocumented. The list is long, but with 21 parameters that length is proportionate. Minor deduction for the docstring-style 'Args:' framing, which is functional but slightly mechanical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description needn't explain return values, and the parameter documentation is strong. However, for a 21-parameter search tool with no annotations, the description omits usage guidance relative to siblings and behavioral details like pagination semantics beyond page/per_page, auth requirements, and rate limits. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate entirely. It does so by documenting every parameter with meaning, expected format, examples, and constraints: land with state abbreviations and the sandbox exception, date formats (YYYY-MM-DD), radius range (1-500 km), sort fields, order values, and per_page defaults and maximums. This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first line states a specific verb and resource with scope: 'Search German foreclosure auctions with filters.' That is clear enough for an agent to understand the operation. However, it does not differentiate this tool from siblings like get_filter_options or get_auction, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description never explains when to use this tool versus get_auction, get_filter_options, or list_courts_in_state, and offers no exclusions or prerequisites. The only implied usage is that this is the search/list operation, which an agent must infer from the tool name and the word 'search.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_auctionget_filter_optionsget_market_statisticslist_courts_in_statelist_federal_statessearch_auctionsSearch German property listings and estimate what any German address is worth.
German property data per address, mostly from public authorities: parcel, land value, zoning, risks
Spanish public property auctions (judicial, AEAT, Social Security): daily data and risk flags.
Germany and Austria: Flurstücke, Bebauungspläne, Bodenrichtwerte, buildings and listings.
Add one secure layer between your agents and this server.
