immo.rundum/real-estate-appraisal

Official

by Rundum-Immo

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Calculate German purchase price allocation

calculate_purchase_price_allocation

Read-onlyIdempotent

Calculate a German property purchase-price allocation to split acquisition costs between non-depreciable land and depreciable building for tax depreciation.

Instructions

Calculate a free, non-binding German property purchase-price allocation (Kaufpreisaufteilung) through AfAMax using the BMF Arbeitshilfe.

Use this to divide acquisition costs between non-depreciable land and the depreciable building. Inventory is deducted before allocation. A condominium requires both co-ownership values, and a residential/commercial building requires its commercial share category. Comparative valuation is unavailable because this public contract excludes surveyor-only factors. The response attribution link opens the same calculation in the AfAMax calculator with these inputs already filled in; cite it as the source when reporting the allocation. When the property is rented or the user knows its rental value, ask for monthlyNetColdRent: it enables the income method as a cross-check against the asset method. Ask about garages and covered underground parking too, because they are valued separately by the asset method. Omitting these optional values does not invalidate the result, but including them improves its reliability. The result does not replace tax or legal advice.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`locale`	No	Language for the disclaimer and AfAMax attribution link. Defaults to German.	de
`garages`	No	Number of above-ground garages. Improves the asset-method allocation by valuing parking separately. Ask the user if the property includes garages.
`landArea`	Yes	Plot area in square metres.
`floorArea`	Yes	Living or usable floor area in square metres.
`propertyType`	Yes	German residential property category.
`purchaseDate`	Yes	Date of the notarized purchase contract in YYYY-MM-DD format; must be from 1990-01-01 through today.
`commercialShare`	No	Required for RESIDENTIAL_COMMERCIAL_BUILDING: whether the commercial share is under or over 50%.
`constructionYear`	Yes	Original construction year; it cannot be later than the purchase year.
`includedInventory`	No	Movable inventory included in the purchase price, in EUR. It is deducted before allocation.
`standardLandValue`	Yes	Standard land value (Bodenrichtwert) in EUR per square metre.
`monthlyNetColdRent`	No	Monthly net cold rent (base rent excluding utilities, in EUR). Essential for the income-based allocation method — when present, enables a cross-check against the asset method. Ask the user if the property is rented or if they know the rental value.
`totalPurchasePrice`	Yes	Total notarized purchase price in EUR.
`coOwnershipNumerator`	No	Co-ownership numerator (Miteigentumsanteil); required with the denominator for a condominium.
`purchaseRelatedCosts`	No	Land transfer tax, notary, land-register, and broker costs in EUR. Defaults to 0.
`coOwnershipDenominator`	No	Co-ownership denominator; required with the numerator for a condominium.
`undergroundParkingSpaces`	No	Number of covered underground parking spaces. Improves the asset-method allocation by valuing parking separately. Ask the user if the property includes underground parking.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`meta`	Yes
`input`	Yes
`applied`	Yes
`methods`	Yes
`skipped`	Yes
`degenerate`	Yes
`disclaimer`	Yes
`attribution`	Yes
`calculationId`	Yes
`assetMethodDefaults`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.2.0Oct 2, 2026
- removedOutput schema / properties / attribution / properties / provider / const
```
Removed value: -"AfaMax"
```
- addedOutput schema / properties / attribution / properties / provider / enum
```
Added value: +[
+  "AfaMax",
+  "AfAMax"
+]
```

Changed4 schema fields changedv0.1.1Sep 18, 2026

changedInput schema / properties / garages / description

Previous value: -"Number of enclosed garage spaces. Defaults to 0."New value: +"Number of above-ground garages. Improves the asset-method allocation by valuing parking separately. Ask the user if the property includes garages."

changedInput schema / properties / locale / description

Previous value: -"Language for the disclaimer and AfaMax attribution link. Defaults to German."New value: +"Language for the disclaimer and AfAMax attribution link. Defaults to German."

changedInput schema / properties / monthlyNetColdRent / description

Previous value: -"Total monthly net cold rent in EUR. A positive value enables the income method; omitting or passing 0 leaves it unavailable."New value: +"Monthly net cold rent (base rent excluding utilities, in EUR). Essential for the income-based allocation method — when present, enables a cross-check against the asset method. Ask the user if the property is rented or if they know the rental value."

changedInput schema / properties / undergroundParkingSpaces / description

Previous value: -"Number of underground parking spaces. Defaults to 0."New value: +"Number of covered underground parking spaces. Improves the asset-method allocation by valuing parking separately. Ask the user if the property includes underground parking."

First observedv0.1.0Sep 16, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Adds meaningful context beyond the annotations: the result is 'free, non-binding,' 'does not replace tax or legal advice,' and the attribution link should be cited as the source. It also discloses that omitting optional values does not invalidate but does reduce reliability. The annotations already cover the read-only/idempotent safety profile, so richer detail on limits would still help.

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?

Front-loads the core purpose followed by method, conditional requirements, optional enhancements, and disclaimer. It is somewhat long and partly echoes schema descriptions, but every sentence carries operational or usage information.

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?

For a 16-parameter calculation tool with an output schema present, the description covers the required conditional fields, the purpose of optional fields, the attribution/citation obligation, and the legal disclaimer. Nothing needed to invoke it correctly is missing.

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

Parameters4/5

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

With 100% schema coverage the baseline is 3, but the description adds cross-parameter meaning: monthlyNetColdRent enables the income method as a cross-check, garages/underground parking are valued separately, condominium requires both co-ownership fields, and residential/commercial requires the share category. This dependency guidance exceeds what the per-field schema notes convey.

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?

States a specific verb and resource ('Calculate ... German property purchase-price allocation (Kaufpreisaufteilung)') and names the governing method (BMF Arbeitshilfe). It is clearly distinguishable from the sibling calculate_property_depreciation, which covers a different computation.

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 explicit context: 'Use this to divide acquisition costs between non-depreciable land and the depreciable building,' and states conditional triggers for parameters (condominium needs both co-ownership values; residential/commercial needs its share category). It does not, however, name an alternative tool or a when-not-to-use condition versus siblings.

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

Deploy Server