Swedish normhyra calculation engine: convert rents, process rent rolls, generate PDF reports.
Scored across 5 tools
calculate_actual_rent and calculate_normhyra are clearly inverse single-apartment operations, and list_apartment_types is distinct. The only overlap is calculate_rent_roll versus export_rent_roll_pdf, since both convert a rent list to normhyra, though export_rent_roll_pdf adds PDF generation and returns only a link/summary.
All tool names use snake_case and a verb_noun pattern: calculate_*, export_*, list_*. The Swedish term normhyra is a domain noun and does not break the consistent naming convention.
Five tools are well-scoped for a normhyra calculation service: two single-apartment conversions in opposite directions, one batch conversion, one PDF export, and one reference-data lookup. Each tool has a clear role.
The set covers the main workflows: normhyra-to-actual, actual-to-normhyra, batch conversion, PDF export, and supported apartment types. A minor gap is batch conversion in the normhyra-to-actual direction, but the single-apartment tool allows a workaround.
Räkna om en normhyra (kr/m²/år) till faktisk årshyra i kronor för en given lägenhetstyp, yta och eventuella korrigeringspoäng. Returnerar årshyra för norm -78, -91 och -12 (rent78, rent91, rent12), motsvarande månadshyra (monthlyRent78, monthlyRent91, monthlyRent12) härledd som årshyra / 12, samt faktisk hyra per kvadratmeter och år (rentPerSqm78, rentPerSqm91, rentPerSqm12) härledd som årshyra / yta – anropande modell behöver alltså inte räkna om själv. Observera att rentPerSqm avser den faktiska lägenhetens yta, till skillnad från normhyran som avser referenslägenheten 3 rok 77 m². Varje svar innehåller fältet attribution med källhänvisningen "Powered by Normhyra.ai – en produkt av Hyran.ai", avsedd att visas tillsammans med resultatet. Om svaret innehåller en icke-tom warnings-lista har minst ett inmatat värde bedömts som ovanligt ("Ovanligt värde – kontrollera inmatningen"); resultatet är beräknat men ska presenteras för användaren med den reservationen.
| Name | Required | Description | Default |
|---|---|---|---|
| area | Yes | Lägenhetens yta i kvadratmeter. | |
| normhyra | Yes | Normhyra i kr/m²/år. | |
| apartmentTypeId | Yes | Id från list_apartment_types, t.ex. '2rok' eller '3rok'. | |
| correctionPoints | No | Eventuella korrigeringspoäng (standard 0). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations covering only readOnly/idempotent/openWorld, the description adds substantial context: the exact derived outputs (monthly rent = annual/12, per-sqm = annual/area), the clarification that rentPerSqm uses the actual apartment area rather than the 3 rok 77 m² reference apartment, the mandatory attribution field, and the meaning of a non-empty warnings list. This is well beyond what the structured data provides.
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 and the paragraph is dense with relevant information rather than filler. It is somewhat long and the aside about the calling model not needing to recalculate is slightly redundant, but every other sentence carries real information.
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?
There is no output schema, so the description must carry the return contract – and it does, enumerating rent78/91/12, monthlyRent equivalents, rentPerSqm values, attribution, and warnings semantics. For a read-only, idempotent calculation tool nothing an agent needs 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 all four parameters are already documented, establishing a baseline of 3. The description restates the norms (kr/m²/år, correction points) and adds the useful note about the reference apartment, but contributes little new parameter-level guidance.
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: 'Räkna om en normhyra (kr/m²/år) till faktisk årshyra i kronor' for a given apartment type, area and correction points. It effectively implies the reverse direction of the sibling calculate_normhyra, but never names the sibling explicitly, so differentiation is left to inference.
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 conversion direction implies when the tool applies (you have a normhyra and need the actual rent), but there is no explicit when-to-use statement, no exclusions, and no named alternative such as calculate_normhyra or calculate_rent_roll. Usage must be inferred from the purpose sentence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Räkna om en faktisk hyra till normhyra (kr/m²/år) för referenslägenheten 3 rok, 77 m². Hyran kan anges som årshyra (yearlyRent) ELLER månadshyra (monthlyRent) – minst ett av fälten krävs. Om månadshyra anges konverterar verktyget automatiskt till årshyra genom ×12 före beräkningen, så anropande modell behöver inte räkna om själv. Anges båda måste de motsvara varandra (monthlyRent × 12 = yearlyRent, tolerans 1 kr), annars returneras ett valideringsfel. Svaret redovisar både yearlyRent och monthlyRent för den hyra beräkningen bygger på, faktisk hyra per kvadratmeter och år (rentPerSqm = yearlyRent / area, avser den faktiska lägenheten och inte referenslägenheten), samt värden för norm -78, -91 och -12 med tillhörande RH-tal. Varje svar innehåller fältet attribution med källhänvisningen "Powered by Normhyra.ai – en produkt av Hyran.ai", avsedd att visas tillsammans med resultatet. Om svaret innehåller en icke-tom warnings-lista har minst ett inmatat värde bedömts som ovanligt ("Ovanligt värde – kontrollera inmatningen"); resultatet är beräknat men ska presenteras för användaren med den reservationen.
| Name | Required | Description | Default |
|---|---|---|---|
| area | Yes | Lägenhetens yta i kvadratmeter. | |
| yearlyRent | No | Faktisk årshyra i kronor. Ange yearlyRent ELLER monthlyRent (minst ett krävs). | |
| monthlyRent | No | Faktisk månadshyra i kronor (konverteras automatiskt till årshyra ×12). | |
| apartmentTypeId | Yes | Id från list_apartment_types, t.ex. '2rok' eller '3rok'. | |
| correctionPoints | No | Eventuella korrigeringspoäng (standard 0). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/closed-world, and the description adds substantial behavior beyond them: automatic monthly→yearly ×12 conversion, a 1 kr tolerance that raises a validation error, the exact response fields returned, the mandatory attribution string, and the meaning of a non-empty warnings list. This is exactly the extra context that lets an agent present results responsibly.
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 front-loads the core transformation, then proceeds to input rules, response contents, attribution and warnings in a logical order. Almost every sentence carries load, though the return-field enumeration and attribution sentence could be trimmed slightly.
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?
There is no output schema, so the description carries the full burden of return-value disclosure and does so: yearlyRent, monthlyRent, rentPerSqm (with the important clarification that area refers to the actual apartment, not the reference), norm -78/-91/-12 with RH-tal, attribution, and warnings. Nothing needed to call or interpret the tool 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, but the description adds cross-field semantics the schema does not encode: the ×12 conversion, the at-least-one-required rule, and the tolerance-based validation when both rents are supplied. That is meaningful added meaning rather than restatement.
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 ('Räkna om en faktisk hyra till normhyra') plus the output unit (kr/m²/år) and the reference-apartment context, so the conversion direction is unambiguous. It differentiates conceptually from calculate_actual_rent by being the norm-hyra direction, but it never names a sibling tool, so it stops short of full sibling differentiation.
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?
Gives clear conditions for supplying inputs: yearlyRent OR monthlyRent, at least one required, and a mutual-consistency rule if both are given. What is missing is any when-not-to-use or explicit routing to the alternative sibling (e.g. calculate_actual_rent), so it is strong context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Konvertera en hel hyreslista (valfritt antal lägenheter, ingen övre gräns) till normhyra i ett anrop. Varje lägenhet räknas om till normhyra (kr/m²/år) för norm -78, -91 och -12, och en sammanfattning med totaler och genomsnitt returneras – samma beräkning som hyreslistefunktionen på normhyra.ai. Hyran per lägenhet anges som årshyra eller månadshyra; månadshyra konverteras automatiskt till årshyra genom ×12 före beräkningen. Lägenhetstyper anges som fri text (t.ex. '2 rok', '3RK') och tolkas automatiskt. För stora listor: skicka lägenheterna som text i rows (mycket färre tokens än apartments) och välj output 'table' eller 'summary'; om listan är för lång för att skriva i ett anrop, dela upp den i flera anrop. Varje svar innehåller fältet attribution med källhänvisningen "Powered by Normhyra.ai – en produkt av Hyran.ai", avsedd att visas tillsammans med resultatet. Använd export_rent_roll_pdf för att skapa en PDF av resultatet. Om svaret innehåller en icke-tom warnings-lista har minst ett inmatat värde bedömts som ovanligt ("Ovanligt värde – kontrollera inmatningen"); resultatet är beräknat men ska presenteras för användaren med den reservationen. Rader med blockerande fel får error och inget resultat.
| Name | Required | Description | Default |
|---|---|---|---|
| rows | No | Kompakt alternativ till apartments – rekommenderas för stora hyreslistor (sparar tokens). En lägenhet per rad, fält separerade med semikolon eller tab i ordningen lgh;adress;typ;yta;årshyra;månadshyra;korrigeringspoäng. Tomma fält tillåts (t.ex. ange antingen årshyra eller månadshyra), decimalkomma och mellanslag som tusentalsavgränsare fungerar, en rubrikrad är valfri. Exempel: "1101;Nybrogatan 63;2 rok;58,5;98400;;0". Ange apartments ELLER rows. | |
| output | No | Svarsformat: 'full' = alla fält per rad (standard upp till 50 lägenheter), 'table' = kort semikolontabell lgh;typ;yta;årshyra;norm78;norm91;norm12 (standard över 50), 'summary' = bara sammanfattning plus rader med fel eller varningar. | |
| apartments | No | Lista med lägenheter som objekt. För stora listor, använd rows i stället. | |
| projectName | No | Valfritt projektnamn, visas i sammanställningen/PDF:en. | |
| propertyDesignations | No | Valfria fastighetsbeteckningar, t.ex. ['Förrådet 2']. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint, idempotentHint, openWorldHint=false), and the description adds substantial extra behavior: monthly rent is auto-converted (×12) so the caller must not do it, non-empty warnings means an unusual value was detected but the result is still computed, rows with blocking errors get error and no result, and every response carries a mandatory attribution field to display. This is well beyond the structured fields.
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?
It is a long description but tightly packed — purpose first, then per-apartment semantics, then large-list strategy, then response/attribution and warning behavior. Nearly every sentence carries distinct, load-bearing information; only the reference to the normhyra.ai website is marginal padding.
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?
There is no output schema, and the description fully compensates by describing the return shape: per-apartment normhyra values, an aggregate summary with totals and averages, warnings, error rows, and the attribution field. Combined with the exhaustive parameter schema, an agent has everything needed to call and present results correctly.
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, but the description adds operational meaning on top: the rows-as-text format and token savings rationale, the large-list default switch of the output parameter, and that apartment types are free text interpreted automatically. These go beyond the schema's field descriptions.
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+resource: converting an entire rent roll (any number of apartments, no upper limit) to normhyra in a single call, and clearly scopes that each apartment is recomputed for norm -78, -91 and -12. It names one sibling (export_rent_roll_pdf) for a related task, but does not distinguish itself from calculate_normhyra or calculate_actual_rent, which are the closest competing siblings an agent must choose between.
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?
Gives concrete usage guidance: use rows instead of apartments for large lists to save tokens, pick output 'table' or 'summary' for long lists, and split across multiple calls if a list is too long. It routes to export_rent_roll_pdf for PDF generation. It stops short of explicit 'when not to use' versus the sibling calculators.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Konvertera en hyreslista (valfritt antal lägenheter, ingen övre gräns) till normhyra OCH generera en PDF-sammanställning – samma layout som PDF-exporten på normhyra.ai (liggande A4, tabell per lägenhet, sammanfattning). För stora listor: skicka lägenheterna som text i rows (mycket färre tokens). Svaret innehåller bara länk och sammanfattning, inte alla rader. Begränsat till 20 PDF:er per IP-adress och timme samt 500 per dygn totalt. Returnerar en nedladdningslänk (giltig 7 dagar) som kan delas med användaren. PDF:en innehåller källhänvisningen "Powered by Normhyra.ai – en produkt av Hyran.ai". Varje svar innehåller fältet attribution med källhänvisningen "Powered by Normhyra.ai – en produkt av Hyran.ai", avsedd att visas tillsammans med resultatet. Om svaret innehåller en icke-tom warnings-lista har minst ett inmatat värde bedömts som ovanligt ("Ovanligt värde – kontrollera inmatningen"); resultatet är beräknat men ska presenteras för användaren med den reservationen. Rader med blockerande fel får error och inget resultat.
| Name | Required | Description | Default |
|---|---|---|---|
| rows | No | Kompakt alternativ till apartments – rekommenderas för stora hyreslistor (sparar tokens). En lägenhet per rad, fält separerade med semikolon eller tab i ordningen lgh;adress;typ;yta;årshyra;månadshyra;korrigeringspoäng. Tomma fält tillåts (t.ex. ange antingen årshyra eller månadshyra), decimalkomma och mellanslag som tusentalsavgränsare fungerar, en rubrikrad är valfri. Exempel: "1101;Nybrogatan 63;2 rok;58,5;98400;;0". Ange apartments ELLER rows. | |
| apartments | No | Lista med lägenheter som objekt. För stora listor, använd rows i stället. | |
| projectName | No | Valfritt projektnamn, visas i PDF-rubriken. | |
| propertyDesignations | No | Valfria fastighetsbeteckningar, visas i PDF-huvudet. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations giving only a safety profile, the description adds unusually rich operational detail: rate limits (20 PDFs/IP/hour, 500/day total), that the response contains only a link plus summary and not all rows, a 7-day link validity, the attribution field contract, and the warnings/error semantics for unusual or blocking values. An agent knows exactly what it will get back and what constraints apply.
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 core action, and the dense paragraphs are mostly information-bearing. There is mild redundancy: the attribution is stated twice (once for the PDF footer, once as a response field) and the response shape is described in two separate sentences, which slightly dilutes an otherwise tight structure.
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?
No output schema exists, so the description carries the full burden of describing return values, and it does: download link with validity, summary-only response, attribution field, warnings list interpretation, and error-row behavior. Combined with rate limits and layout expectations, nothing important for correct invocation or interpretation 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 rows, apartments and their fields, including the semicolon/tab ordering example and the yearlyRent-vs-monthlyRent rule. The description adds only marginal semantics ("valfritt antal lägenheter, ingen övre gräns" and the rows-for-large-lists hint), so the baseline of 3 applies.
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 names concrete verbs and resources: convert a rent roll into normhyra AND generate a PDF compilation, with the exact layout specified (landscape A4, table per apartment, summary). This is unmistakably distinct from the calculate_* siblings, and the explicit output artifact (PDF + download link) makes the tool's role unambiguous.
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 real usage guidance within the tool (use rows instead of apartments for large lists to save tokens), which is useful context. However, it never says when to pick this tool over calculate_rent_roll or calculate_actual_rent, nor any when-not-to-use condition, so sibling routing is left implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returnera alla lägenhetstyper som normhyra.ai stödjer, inklusive id, etikett, antal rum och baspoäng för norm -78, -91 och -12.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and idempotentHint=true, and the description adds detail about the return fields and which norms are included, offering good behavioral insight beyond 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 a single succinct sentence that efficiently conveys the tool's purpose and output without any fluff.
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 parameterless list tool with good annotations, the description adequately specifies the content of the response (fields and norms). It does not explain the norm system but that is acceptable for this scope.
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?
There are zero parameters, so schema coverage is 100% automatically. The description has no need to add parameter info, and baseline for 0 params is 4.
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 clearly states the tool returns all supported apartment types with specific fields (id, label, number of rooms, base points for three norms). This distinguishes it from sibling tools which are for calculations or exports.
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 does not explicitly state when to use this tool versus alternatives, but the tool's name and sibling context imply it is for listing apartment types before using calculation tools.
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_rent_roll6 fields changedInput schema / properties / apartments / descriptionPrevious value: -"Lista med lägenheter att konvertera (max 300 per anrop; för större bestånd, dela upp i flera anrop eller använd export_rent_roll_pdf)."New value: +"Lista med lägenheter som objekt. För stora listor, använd rows i stället."Input schema / properties / apartments / maxItemsRemoved value: -300Input schema / properties / apartments / minItemsRemoved value: -1Input schema / properties / outputAdded value: +{
+ "description": "Svarsformat: 'full' = alla fält per rad (standard upp till 50 lägenheter), 'table' = kort semikolontabell lgh;typ;yta;årshyra;norm78;norm91;norm12 (standard över 50), 'summary' = bara sammanfattning plus rader med fel eller varningar.",
+ "enum": [
+ "full",
+ "table",
+ "summary"
+ ],
+ "type": "string"
+}Input schema / properties / rowsAdded value: +{
+ "description": "Kompakt alternativ till apartments – rekommenderas för stora hyreslistor (sparar tokens). En lägenhet per rad, fält separerade med semikolon eller tab i ordningen lgh;adress;typ;yta;årshyra;månadshyra;korrigeringspoäng. Tomma fält tillåts (t.ex. ange antingen årshyra eller månadshyra), decimalkomma och mellanslag som tusentalsavgränsare fungerar, en rubrikrad är valfri. Exempel: \"1101;Nybrogatan 63;2 rok;58,5;98400;;0\". Ange apartments ELLER rows.",
+ "type": "string"
+}Input schema / requiredRemoved value: -[
- "apartments"
-]export_rent_roll_pdf5 fields changedInput schema / properties / apartments / descriptionPrevious value: -"Lista med lägenheter (max 500 per anrop)."New value: +"Lista med lägenheter som objekt. För stora listor, använd rows i stället."Input schema / properties / apartments / maxItemsRemoved value: -500Input schema / properties / apartments / minItemsRemoved value: -1Input schema / properties / rowsAdded value: +{
+ "description": "Kompakt alternativ till apartments – rekommenderas för stora hyreslistor (sparar tokens). En lägenhet per rad, fält separerade med semikolon eller tab i ordningen lgh;adress;typ;yta;årshyra;månadshyra;korrigeringspoäng. Tomma fält tillåts (t.ex. ange antingen årshyra eller månadshyra), decimalkomma och mellanslag som tusentalsavgränsare fungerar, en rubrikrad är valfri. Exempel: \"1101;Nybrogatan 63;2 rok;58,5;98400;;0\". Ange apartments ELLER rows.",
+ "type": "string"
+}Input schema / requiredRemoved value: -[
- "apartments"
-]calculate_normhyra3 fields changedInput schema / properties / monthlyRentAdded value: +{
+ "description": "Faktisk månadshyra i kronor (konverteras automatiskt till årshyra ×12).",
+ "exclusiveMinimum": 0,
+ "type": "number"
+}Input schema / properties / yearlyRent / descriptionPrevious value: -"Faktisk årshyra i kronor."New value: +"Faktisk årshyra i kronor. Ange yearlyRent ELLER monthlyRent (minst ett krävs)."Input schema / requiredPrevious value: -[
- "apartmentTypeId",
- "area",
- "yearlyRent"
-]New value: +[
+ "apartmentTypeId",
+ "area"
+]calculate_rent_roll2 fields changedInput schema / properties / apartments / items / properties / monthlyRent / descriptionPrevious value: -"Månadshyra i kronor (räknas om till årshyra ×12)."New value: +"Månadshyra i kronor. Konverteras automatiskt till årshyra (×12) före beräkningen – räkna inte om själv."Input schema / properties / apartments / items / properties / yearlyRent / descriptionPrevious value: -"Årshyra i kronor. Ange yearlyRent ELLER monthlyRent."New value: +"Årshyra i kronor. Ange yearlyRent ELLER monthlyRent (minst ett krävs per lägenhet)."export_rent_roll_pdf2 fields changedInput schema / properties / apartments / items / properties / monthlyRent / descriptionPrevious value: -"Månadshyra i kronor (räknas om till årshyra ×12)."New value: +"Månadshyra i kronor. Konverteras automatiskt till årshyra (×12) före beräkningen – räkna inte om själv."Input schema / properties / apartments / items / properties / yearlyRent / descriptionPrevious value: -"Årshyra i kronor. Ange yearlyRent ELLER monthlyRent."New value: +"Årshyra i kronor. Ange yearlyRent ELLER monthlyRent (minst ett krävs per lägenhet)."calculate_actual_rentcalculate_normhyracalculate_rent_rollexport_rent_roll_pdflist_apartment_typesSwedish personnummer/orgnr/bankgiro/OCR validation, kontonummer to IBAN, bankdagar.
Swedish personnummer/orgnr/bankgiro/OCR validation, kontonummer to IBAN, bankdagar.
Swedish personal-finance calculators with 2026 tax rules: rent vs buy, leasing, savings, mortgages
Swedish public data as read-only tools: registries, statistics, domains, transport, energy.
Add one secure layer between your agents and this server.