Skip to main content
Glama

Austrian property purchase costs

estimate_acquisition_costs
Read-onlyIdempotent

Calculate the one-off costs of buying residential property in Austria on top of the price (Kaufnebenkosten): real estate transfer tax (Grunderwerbsteuer), land-register court fees, broker commission with a check against the legal maximum, and lawyer/notary contract costs, each with VAT where it applies. Use when someone asks what buying a specific flat or house in Austria costs in total. The JSON lists the cited legal bases and sources once; pass detail "full" for every line item with its calculation and its own citations. Amounts in EUR. Not covered: bank or valuation fees, purchases within the family, exemptions for a primary residence.

Input Schema

NameRequiredDescriptionDefault
brokerYesBroker commission, or "none" if the purchase is commission-free (provisionsfrei).
detailNoHow much of the result to return as JSON. "summary" (default) keeps the key figures, flags, assumptions, limitations and deduplicated citations (about 40% of the size for underwrite_property, 60% for estimate_acquisition_costs). "full" adds every line item with its calculation and citations, the tax years and the rules used. The readable text is the same in both.
financingNoMortgage financing, if any. Adds the court fee for registering the mortgage.
assumptionsNoOverride default assumptions. Omit to use documented defaults.
purchasePriceYesPurchase price in EUR (the agreed price for the property), e.g. 249000.
valuationDateNoDate whose rules apply, YYYY-MM-DD, usually today or the expected signing date. Defaults to today (Vienna time). Covered: 2025-04-01 to 2027-12-31.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / detail
      Added value: +{
      +  "description": "How much of the result to return as JSON. \"summary\" (default) keeps the key figures, flags, assumptions, limitations and deduplicated citations (about 40% of the size for underwrite_property, 60% for estimate_acquisition_costs). \"full\" adds every line item with its calculation and citations, the tax years and the rules used. The readable text is the same in both.",
      +  "enum": [
      +    "summary",
      +    "full"
      +  ],
      +  "type": "string"
      +}
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/closed-world, and the description adds real behavioral context on top: the result deduplicates cited legal bases and sources, the broker commission is validated against the legal maximum, and detail='full' expands every line item with its own calculation and citations. It stops short of describing error behavior or how the legal-max check is reported when exceeded.

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?

Four sentences, front-loaded with the calculation scope, then usage, then output behavior, then exclusions. Every sentence carries information, though the cost-component enumeration and the detail explanation make it denser than strictly necessary.

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?

With no output schema, the description carries the return-value burden and does so: it says the JSON contains citations and legal bases, what 'full' adds, and that amounts are in EUR. Combined with the schema's documented defaults, covered date range, and assumption overrides, an agent has everything needed to invoke and interpret the tool.

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?

Schema coverage is 100%, so the baseline is 3, and the description adds meaning beyond it: it explains that detail='full' returns every line item with calculations and citations versus the deduplicated summary, and fixes the unit as EUR. It does not add anything for purchasePrice, financing, or assumptions, which rely entirely on 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?

States a specific verb (calculate) and resource (one-off Austrian residential purchase costs) and enumerates the exact cost components: transfer tax, land-register fees, broker commission, notary/lawyer fees, each with VAT treatment. The scope is narrowed to Austria and residential, so an agent can distinguish it from a generic underwriting or rules tool 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.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit trigger ('Use when someone asks what buying a specific flat or house in Austria costs in total') and an explicit exclusion list (bank/valuation fees, family purchases, primary-residence exemptions). It does not, however, name or contrast the sibling tools get_rules or underwrite_property, so the routing guidance is clear but not complete.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.