German property depreciation (AfA), Restnutzungsdauer, Kaufpreisaufteilung & appraisals via AfAMax
Scored across 5 tools
Each tool has a clearly distinct purpose: booking vs listing appointments, two different financial calculators (depreciation vs purchase price allocation), and price lookup. The detailed descriptions give explicit guidance on when to use which tool, minimizing misselection.
All tool names follow a consistent snake_case verb_noun pattern: book_appointment, get_available_appointments, calculate_property_depreciation, calculate_purchase_price_allocation, and get_price_by_product. No deviations or mixed conventions are present.
Five tools are well-scoped for the server's purpose: booking, availability, two self-service calculators, and pricing. Each tool earns its place without redundancy or unnecessary bloat.
The surface covers the core self-service workflows (booking, availability, depreciation and purchase-price allocation calculators, pricing). Minor gaps exist, such as no direct tool to manage or cancel appointments or retrieve full product details beyond price, but these do not block primary workflows.
Books a free 15-minute initial phone call with the AfAMax team, in two steps.
STEP 1: after the user picked a slot from get_available_appointments, confirm the slot, their name and their own e-mail address with them, then call with startDateTime, name, email (and optionally phone, locale). AfAMax e-mails a 6-digit code to that address and returns status "verification_required" with a verificationId.
STEP 2: ask the user for the code from that e-mail and call again with only verificationId and otp. The code proves the address belongs to the user: use only the code the user gives you — never guess, invent or repeatedly retry codes. On success status is "booked" and a calendar invitation goes to the user.
Codes expire after 15 minutes and allow 5 attempts. If the slot was taken meanwhile, list slots again and offer another. If the e-mail belongs to an existing AfAMax account, the user must log in and book on the website (link in the error). Only book for the person you are talking to.
| Name | Required | Description | Default |
|---|---|---|---|
| otp | No | Step 2 — the 6-digit code the user received by e-mail. Only ever the code the user gives you; never guess or retry codes. / Der 6-stellige Code aus der E-Mail. | |
| name | No | Step 1 — the user's full name. / Vor- und Nachname. | |
| No | Step 1 — the user's own e-mail address; the 6-digit confirmation code is sent there. Confirm it with the user before calling. / E-Mail-Adresse für den Bestätigungscode. | ||
| phone | No | Step 1, optional — phone number for the call. / Telefonnummer für das Gespräch. | |
| locale | No | Step 1 — language of the confirmation e-mail, the appointment and the links (`de` if omitted); match the user's language. Step 2 keeps step 1's language unless set. / Sprache der E-Mails und des Termins. | |
| startDateTime | No | Step 1 — the chosen slot, copied exactly from get_available_appointments `startDateTime`. | |
| verificationId | No | Step 2 — the `verificationId` returned by step 1. |
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| status | Yes | `verification_required`: ask the user for the code sent to `verification.maskedEmail`, then call again with verificationId + otp. `booked`: the appointment exists. |
| requestId | Yes | |
| appointment | Yes | |
| attribution | Yes | |
| verification | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a non-read-only, open-world, non-idempotent, non-destructive mutation. The description adds substantial behavioral context beyond that: a two-call OTP flow, intermediate status 'verification_required', verificationId return, 15-minute expiry, 5 attempts, calendar invitation on success, and error handling for taken slots or existing accounts. No contradiction with annotations.
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 long but well-structured, with STEP 1 and STEP 2 labels and the critical constraint ('never guess, invent or repeatedly retry codes') highlighted. Most sentences earn their place by covering verification, expiry, retries, and error alternatives. A small amount of repetition with the schema descriptions keeps it from being maximally tight.
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 two-step, open-world booking tool with 7 parameters and an output schema, the description covers everything an agent needs: sequencing, required inputs per step, OTP rules, error cases, and identity restrictions. Return values are left to the output schema, which is appropriate.
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 100%, so the schema already carries parameter meanings and constraints. The description still adds value by grouping parameters into step 1 vs step 2, clarifying that step 2 should be called with only verificationId and otp, and reinforcing that email must be the user's own address. That is useful operational framing beyond the schema, though not exhaustive per-parameter detail.
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 precise verb and resource ('Books a free 15-minute initial phone call with the AfAMax team') and immediately frames it as a two-step process. It also names the sibling get_available_appointments as the source of the slot, so an agent can distinguish this from the other appointment/pricing tools without opening schemas.
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 explicit when-to-use and step-by-step conditions: step 1 only after the user picks a slot from get_available_appointments and confirms name/email, step 2 only with the e-mailed code. It also states when not to proceed (slot taken, existing account email) and the alternative action for each, plus a firm usage restriction ('Only book for the person you are talking to').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate indicative German property depreciation (AfA / Gebäudeabschreibung) and the building's remaining useful life (Restnutzungsdauer) for residential rental property through AfAMax.
Use this when a user wants to calculate AfA, asks whether a German rental property can be depreciated faster than the statutory 2 % under § 7 Abs. 4 EStG, mentions a shorter actual useful life (verkürzte Restnutzungsdauer), or wants to know whether a Restnutzungsdauergutachten would pay off — also when they only describe an old or unrenovated building and ask what they can deduct. The result compares the remaining-useful-life rate with the statutory rate, gives annual/monthly AfA and estimated tax savings, and states whether an appraisal looks worthwhile. For apartment buildings, pass figures for the whole building or calculate units separately. Ask for all eight modernization component states whenever possible: omitting them assumes no modernization and produces the highest possible remaining-useful-life benefit. 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 result. The result is non-binding and does not replace tax or legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Language for upstream explanations; defaults to German. | |
| taxRate | No | Personal marginal income tax rate as a decimal, e.g. 0.42. / Grenzsteuersatz. | |
| landArea | No | Land area in square metres. / Grundstücksfläche. | |
| floorArea | Yes | Living or usable floor area in square metres. / Wohn- bzw. Nutzfläche. | |
| propertyType | Yes | German residential property category. CONDOMINIUM = Eigentumswohnung, ROW_HOUSE = Reihenhaus, SEMI_DETACHED = Doppelhaushälfte, APARTMENT_BUILDING = Mehrfamilienhaus, RESIDENTIAL_COMMERCIAL_BUILDING = Wohn- und Geschäftshaus. | |
| modernization | No | Known state of eight modernization components (Modernisierungselemente): roof (Dach), facadeInsulation (Fassadendämmung), windowsDoors (Fenster und Außentüren), heating (Heizung), utilities (Leitungen), bathrooms (Bäder), interiorFitout (Innenausbau), floorplanImprovement (Grundrissverbesserung). Ask for all eight when possible. | |
| purchasePrice | No | Total purchase price in EUR. / Kaufpreis. | |
| constructionYear | Yes | Original year of construction. / Baujahr. | |
| includedInventory | No | Movable inventory included in the purchase price, in EUR. | |
| standardLandValue | No | Standard land value in EUR per square metre. / Bodenrichtwert. | |
| coreRenovationYear | No | Year of a qualifying core renovation, if applicable. / Jahr einer Kernsanierung. | |
| modernizationLevel | No | Coarse modernization level used when detailed component data is unavailable. | |
| purchaseRelatedCosts | No | Purchase-related costs in EUR (land transfer tax, notary, land register, broker). / Kaufnebenkosten. |
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| input | Yes | |
| results | Yes | |
| disclaimer | Yes | |
| assumptions | Yes | |
| attribution | Yes | |
| calculationId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey the safe read-only, idempotent profile, and the description layers on substantive behavior: the output compares the RND rate against the statutory rate and yields annual/monthly AfA plus estimated tax savings, the omission of modernization components defaults to 'no modernization' and inflates the benefit, it returns a non-binding result that does not replace tax advice, and it mandates citing the attribution link as the source. This is far beyond what the annotations provide.
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?
Purpose is front-loaded in the first sentence and every subsequent sentence carries distinct content (usage triggers, building-vs-unit rule, modernization default, attribution requirement, disclaimer). It is a single dense block that would scan better segmented, which keeps it from a 5, but there is little waste.
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 13-parameter domain calculator with an output schema, the description covers what an agent needs: when to invoke, the apartment-building input rule, the consequence of omitting customization data, the attribution-citation duty, and the non-binding nature of the result. Return values are also summarized despite the output schema existing.
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 100%, so the baseline is 3 and the schema does most of the work. The description still adds genuine semantic guidance: pass whole-building figures or compute units separately for apartment buildings, and supply all eight modernization component states because omission implies no modernization and produces the maximum RND benefit.
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 precise verb+resource ('Calculate German property depreciation (AfA / Gebäudeabschreibung) and the building's remaining useful life (Restnutzungsdauer)') and scopes it to residential rental property through AfAMax. The purpose is unambiguous and readily separable from the unrelated siblings (appointments, price/product lookups), and even the adjacent real-estate calculator sibling covers a different calculation.
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?
Rich when-to-use triggers: calculating AfA, asking about faster-than-2% depreciation under § 7 Abs. 4 EStG, mentioning verkürzte Restnutzungsdauer, evaluating whether a Restnutzungsdauergutachten pays off, or just describing an old/unrenovated building and asking what is deductible. It lacks any explicit 'when not to use' or named alternative tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 (Grundstücksanteil) and the depreciable building (Gebäudeanteil), e.g. when a user asks how much of the price they may depreciate or wants to check the Finanzamt's split. Its depreciationBase is the base for the building's AfA. 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.
| 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. |
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| input | Yes | |
| applied | Yes | |
| methods | Yes | |
| skipped | Yes | |
| degenerate | Yes | |
| disclaimer | Yes | |
| attribution | Yes | |
| calculationId | Yes | |
| assetMethodDefaults | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description layers on real behavioral context: free/non-binding, inventory deducted before allocation, depreciationBase meaning, the attribution link's behavior and citation obligation, and that omitting optional values does not invalidate the result. This is well beyond what annotations provide.
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?
Front-loaded with the purpose and scope, then moves to required-vs-optional prompting. It is dense across many sentences, and the garage/underground-parking advice is somewhat repetitive of the schema's own descriptions, but every sentence carries actionable content.
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?
With 16 parameters, 7 required, three enums and an output schema present, the description covers the pieces an agent needs that structured fields do not: conditional parameter requirements, the depreciation use case, the optional-value tradeoff, and the disclaimer. Return values need not be explained since an output schema exists.
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 100%, so the baseline is 3, but the description adds cross-parameter conditions not obvious from the schema alone: a condominium needs both co-ownership values, a residential/commercial building needs its commercial share category, and monthlyNetColdRent enables the income method as a cross-check. It adds genuine meaning rather than restating field docs.
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 and resource ('Calculate a free, non-binding German property purchase-price allocation (Kaufpreisaufteilung)') and names the mechanism (BMF Arbeitshilfe via AfAMax). An agent can distinguish this from calculate_property_depreciation without opening either 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?
Explicitly frames the use case ('e.g. when a user asks how much of the price they may depreciate or wants to check the Finanzamt's split'), and states a negative constraint (comparative valuation unavailable because the public contract excludes surveyor-only factors). It also tells the agent which optional inputs to solicit and why, which is guidance a schema cannot give.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists open slots for a free, non-binding 15-minute initial phone call with the AfAMax team (Erstgespräch), on weekdays in the Europe/Berlin time zone, grouped by day.
Each day lists a sample spread across the day (maxSlotsPerDay, default 8) and its freeSlotCount; for a specific time, call again for that day with days: 1 and maxSlotsPerDay: 32. Show the user the day and localTime; to book one, pass its startDateTime unchanged to book_appointment. Slots are live and can be taken at any time, so re-check rather than reusing an old list. The response attribution links to the contact page, where the user can also book directly.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | How many calendar days to look ahead (1-21, default 7). / Anzahl Tage. | |
| from | No | ISO 8601 date-time to start looking from. Defaults to now. / Frühester Zeitpunkt. | |
| locale | No | Language of the link handed back and the response labels. Match the user's language (most users are German-speaking). | de |
| maxSlotsPerDay | No | How many slots to list per day (1-32, default 8), spread evenly across the day. When the user wants a specific time, call again for that day with `days: 1` and `maxSlotsPerDay: 32`. |
| Name | Required | Description |
|---|---|---|
| days | Yes | |
| meta | Yes | |
| timeZone | Yes | |
| requestId | Yes | |
| attribution | Yes | |
| description | Yes | |
| appointmentType | Yes | |
| durationMinutes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnlyHint=true, destructiveHint=false), so the bar is lower. The description adds genuine behavioral context beyond that: slots are live and can be taken at any time, so results go stale, and the response attribution links to a contact page for direct booking.
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?
Front-loaded with what the tool returns and its constraints, then the booking handoff and the freshness warning. Dense but every sentence carries operational value; no 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 return-value explanation isn't required. The description still completes the workflow picture: timezone, weekday constraint, locale behavior, booking handoff, and staleness warning. Nothing an agent needs to route or call correctly is missing.
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 100%, so the baseline is 3. The description goes further by explaining how to use maxSlotsPerDay in practice (a sample spread across the day, default 8) and the specific re-call pattern with days:1 and maxSlotsPerDay:32 for a targeted time, which is not derivable from the schema alone.
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 (lists) and resource (open appointment slots) with scope details: free, non-binding, 15-minute initial phone call, weekdays, Europe/Berlin, grouped by day. An agent can instantly distinguish this from book_appointment and the unrelated calculation siblings.
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?
Explicit routing: for a specific time, re-call with days:1 and maxSlotsPerDay:32; to book, pass startDateTime unchanged to book_appointment; and re-check rather than reusing an old list. The alternative (book_appointment) and the conditions selecting each path are named directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns AfAMax's current list price in EUR, incl. German VAT (19%), for one product — Restnutzungsdauergutachten (rnd), Wertgutachten (kurzgutachten), Verkehrswertgutachten (vollgutachten), Kaufpreisaufteilung or Versetzbarkeitsgutachten — including the options the customer picks when ordering: property inspection (exterior or on-site), express processing and, for multi-unit buildings, a per-flat price.
price.totalPrice is the sum; surchargeTable lists every option so alternatives can be compared without another call. Discount codes are not applied, and the price shown when ordering is binding — say so when quoting. This tool only quotes prices: to estimate whether a Restnutzungsdauergutachten would pay off, use calculate_property_depreciation. The response attribution links to the product page; cite it as the source when reporting the price.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Language of labels and of the link handed back. Match the user's language. | de |
| product | Yes | Which AfAMax product to price. `rnd` — Restnutzungsdauergutachten / remaining-useful-life appraisal, the basis for a higher AfA rate. `kurzgutachten` — Wertgutachten / short value appraisal. `vollgutachten` — Verkehrswertgutachten / full market-value appraisal (§ 194 BauGB). `kaufpreisaufteilung` — Kaufpreisaufteilung / purchase-price allocation report (land vs. building). `versetzbarkeitsgutachten` — Versetzbarkeitsgutachten / relocatability certificate for tiny houses, mobile homes, modular units and containers. | |
| viewingType | No | Property inspection: `none` (remote, default), `exterior` (outside only / Außenbesichtigung) or `interior_exterior` (on-site, inside and outside / Innen- und Außenbesichtigung). Each adds a surcharge. | none |
| propertyType | No | Optional. Together with totalFlatsCount, a two-family, apartment or mixed-use building with more than one flat adds a per-flat price. | |
| expressDelivery | No | Express processing (3-5 business days / Expressbearbeitung). Adds a surcharge unless a free-express promotion is running. | |
| totalFlatsCount | No | Optional. Number of flats in the building / Anzahl Wohneinheiten. |
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| input | Yes | |
| price | Yes | |
| product | Yes | |
| quoteId | Yes | |
| currency | Yes | |
| disclaimer | Yes | |
| attribution | Yes | |
| productLabel | Yes | |
| surchargeTable | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely useful behavior beyond that: discounts are excluded, the ordering price is the binding one, the surchargeTable allows option comparison without a second call, and the attribution link must be cited as the source.
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 core return value is front-loaded and the paragraph earns most of its length given six parameters and multi-component pricing. The dense em-dash product/option lists cost some readability and could be trimmed against the schema's own enumerations.
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 return-value documentation is not required, yet the description still names the key fields (price.totalPrice, surchargeTable) and the attribution link. Nothing an agent needs to select or invoke this tool correctly is missing.
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 100%, so the schema already documents all six parameters, including the per-flat coupling between propertyType and totalFlatsCount. The description restates the product and add-on options but adds no syntax, format, or edge-case detail beyond the schema, making the baseline 3 correct.
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 and resource ('Returns AfAMax's current list price in EUR ... for one product') and enumerates the exact product identifiers it covers. It explicitly scopes itself to quoting prices, which separates it from calculate_property_depreciation and the booking siblings.
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?
Contains an explicit when-not ('This tool only quotes prices: to estimate whether a Restnutzungsdauergutachten would pay off, use calculate_property_depreciation') naming the correct alternative. It also tells the agent what to do with the result ('say so when quoting') and that discount codes do not apply.
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.
calculate_property_depreciation18 fields changedInput schema / properties / constructionYear / descriptionPrevious value: -"Original year of construction."New value: +"Original year of construction. / Baujahr."Input schema / properties / coreRenovationYear / descriptionPrevious value: -"Year of a qualifying core renovation, if applicable."New value: +"Year of a qualifying core renovation, if applicable. / Jahr einer Kernsanierung."Input schema / properties / floorArea / descriptionPrevious value: -"Living or usable floor area in square metres."New value: +"Living or usable floor area in square metres. / Wohn- bzw. Nutzfläche."Input schema / properties / landArea / descriptionPrevious value: -"Land area in square metres."New value: +"Land area in square metres. / Grundstücksfläche."Input schema / properties / modernization / descriptionPrevious value: -"Known state of eight modernization components. Ask for all eight when possible."New value: +"Known state of eight modernization components (Modernisierungselemente): roof (Dach), facadeInsulation (Fassadendämmung), windowsDoors (Fenster und Außentüren), heating (Heizung), utilities (Leitungen), bathrooms (Bäder), interiorFitout (Innenausbau), floorplanImprovement (Grundrissverbesserung). Ask for all eight when possible."Input schema / properties / propertyType / descriptionPrevious value: -"German residential property category."New value: +"German residential property category. CONDOMINIUM = Eigentumswohnung, ROW_HOUSE = Reihenhaus, SEMI_DETACHED = Doppelhaushälfte, APARTMENT_BUILDING = Mehrfamilienhaus, RESIDENTIAL_COMMERCIAL_BUILDING = Wohn- und Geschäftshaus."Input schema / properties / purchasePrice / descriptionPrevious value: -"Total purchase price in EUR."New value: +"Total purchase price in EUR. / Kaufpreis."Input schema / properties / purchaseRelatedCosts / descriptionPrevious value: -"Purchase-related costs in EUR."New value: +"Purchase-related costs in EUR (land transfer tax, notary, land register, broker). / Kaufnebenkosten."Input schema / properties / standardLandValue / descriptionPrevious value: -"Standard land value in EUR per square metre."New value: +"Standard land value in EUR per square metre. / Bodenrichtwert."Input schema / properties / taxRate / descriptionPrevious value: -"Personal marginal tax rate as a decimal, e.g. 0.42."New value: +"Personal marginal income tax rate as a decimal, e.g. 0.42. / Grenzsteuersatz."Output schema / properties / results / properties / afaRatePerYear / descriptionAdded value: +"AfA rate per year from the estimated remaining useful life, as a decimal (0.0333 = 3.33 %)."Output schema / properties / results / properties / annualAfaAmount / descriptionAdded value: +"Annual AfA in EUR at afaRatePerYear."Output schema / properties / results / properties / annualTaxSavings / descriptionAdded value: +"Estimated income tax saved per year by annualAfaAmount at taxRate."Output schema / properties / results / properties / appraisalWorthwhile / descriptionAdded value: +"Whether the remaining-useful-life rate is high enough for a Restnutzungsdauergutachten to look worthwhile."Output schema / properties / results / properties / buildingValue / descriptionAdded value: +"Depreciable building value in EUR (excluding land)."Output schema / properties / results / properties / defaultAfaAmount / descriptionAdded value: +"Annual AfA in EUR at the statutory rate."Output schema / properties / results / properties / defaultAfaRatePerYear / descriptionAdded value: +"Statutory AfA rate under § 7 Abs. 4 EStG for comparison, as a decimal."Output schema / properties / results / properties / remainingUsefulLifeYears / descriptionAdded value: +"Estimated remaining useful life (Restnutzungsdauer) in years."book_appointmentcalculate_property_depreciation2 fields changedOutput schema / properties / attribution / properties / provider / constRemoved value: -"AfaMax"Output schema / properties / attribution / properties / provider / enumAdded value: +[
+ "AfaMax",
+ "AfAMax"
+]calculate_purchase_price_allocation2 fields changedOutput schema / properties / attribution / properties / provider / constRemoved value: -"AfaMax"Output schema / properties / attribution / properties / provider / enumAdded value: +[
+ "AfaMax",
+ "AfAMax"
+]get_available_appointmentsget_price_by_productcalculate_purchase_price_allocation4 fields changedInput schema / properties / garages / descriptionPrevious 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."Input schema / properties / locale / descriptionPrevious 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."Input schema / properties / monthlyNetColdRent / descriptionPrevious 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."Input schema / properties / undergroundParkingSpaces / descriptionPrevious 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."calculate_property_depreciationcalculate_purchase_price_allocationGerman land values (Bodenrichtwerte) by address + land-use type. Coverage varies; not in SH/SN/BY.
Accounting MCP for French LMNP furnished rentals: income, expenses, depreciation, tax return & FEC
Cost segregation study pricing and Year-1 depreciation/tax-savings estimates for US properties.
German federal and Land statutes plus court decisions for agents. Keyless, read-only, CC BY 4.0.
Add one secure layer between your agents and this server.
