Swedish normhyra calculation engine: convert rents, process rent rolls, generate PDF reports.
Scored across 5 tools
Each tool has a clearly distinct purpose: single actual rent conversion, single norm conversion, batch norm conversion, PDF export, and listing apartment types. The inverse relationship between calculate_actual_rent and calculate_normhyra is clear from their names and descriptions, and the batch/PDF tools are explicitly distinguished.
Tool names follow a consistent verb_noun snake_case pattern, with calculate_* for conversion operations, export_rent_roll_pdf for PDF generation, and list_apartment_types for reference data. The naming is predictable and makes the tool set easy to navigate.
Five tools is well-scoped for a specialized rent calculation service. Each tool covers a meaningful workflow without unnecessary redundancy, and the count feels appropriate for both single-unit and bulk use cases.
The tool set covers the core workflows: converting between actual and norm rents, batch conversion, PDF export, and reference data for apartment types. A minor gap is the lack of a batch version of calculate_actual_rent, though agents can work around it by looping over single-unit calls.
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.
| 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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds valuable behavioral context: it explains the derivation of monthly rent (annual/12) and per-sqm rent (annual/area), clarifies that rentPerSqm refers to the actual apartment's area rather than the reference apartment's area, and discloses the attribution field requirement. This goes 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?
The description is a single, information-dense paragraph. It front-loads the core purpose and then details outputs and caveats. It's slightly long but every sentence adds value: the derivation formulas, the reference apartment distinction, and the attribution requirement are all necessary. No wasted words.
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 read-only calculation tool with 100% schema coverage and no output schema, the description is quite complete. It explains the output fields, their derivations, the reference apartment caveat, and the attribution requirement. The only minor gap is that it doesn't explicitly state what happens if correctionPoints is omitted (though the schema says default 0), and it doesn't describe error conditions. But overall, an agent has enough to call it 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 description coverage is 100%, so the schema already documents all four parameters. The description adds context about how the parameters relate (normhyra is per m²/year, area is the actual apartment's area, correctionPoints are optional) but doesn't add syntax or format details beyond the schema. Baseline 3 is appropriate.
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's purpose: converting a normhyra (kr/m²/år) into actual annual rent in kronor for a given apartment type, area, and optional correction points. It specifies the exact outputs (rent78, rent91, rent12, monthly equivalents, and per-sqm values) and distinguishes itself from related tools by naming the reference apartment (3 rok 77 m²) and the attribution requirement.
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 explains when to use this tool: when you need to convert a normhyra to actual rent for a specific apartment. It doesn't explicitly name alternatives or exclusions, but the sibling context (calculate_normhyra, calculate_rent_roll, export_rent_roll_pdf, list_apartment_types) makes the use case clear. The description also notes that the calling model doesn't need to do the conversion itself, which is a useful usage hint.
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.
| 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?
Beyond the readOnly/idempotent annotations, the description discloses automatic ×12 conversion, tolerance-based validation failure when both rents are inconsistent, exact output fields and formulas, and the mandatory attribution field. This substantially exceeds the annotation signal.
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?
Six purposeful sentences are front-loaded with purpose, followed by input rules, validation, output details, and attribution. There is no fluff, and the density is justified by the absence of an output schema.
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 calculation tool with no output schema, the description fully specifies returned values (yearlyRent, monthlyRent, rentPerSqm, norm -78/-91/-12 with RH-tal, attribution) and validation behavior. No critical calling information appears 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?
With 100% schema description coverage the baseline is 3, but the description adds cross-parameter semantics: the yearly/monthly relationship, tolerance, that at least one rent field is required, and rentPerSqm = yearlyRent / area. It leverages the schema well, though correctionPoints is left to 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?
The description opens with a specific verb and resource: 'Räkna om en faktisk hyra till normhyra (kr/m²/år) för referenslägenheten 3 rok, 77 m².' It clearly distinguishes this tool from siblings like calculate_actual_rent and list_apartment_types by naming the normhyra reference and output unit.
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 intended use is strongly implied – a rent-to-normhyra conversion for the fixed 3 rok reference – and input constraints (yearly vs monthly, at least one required) are explicit. However, it does not name alternatives or state when not to use it, e.g. versus calculate_actual_rent, so the guidance is recoverable but not fully explicit.
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 (flera lägenheter) 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 (yearlyRent) eller månadshyra (monthlyRent); månadshyra konverteras automatiskt till årshyra genom ×12 före beräkningen, och varje rad redovisar både yearlyRent och monthlyRent. Lägenhetstyper anges som fri text (t.ex. '2 rok', '3RK') och tolkas automatiskt. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| apartments | Yes | 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). | |
| 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?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses important behavior: monthlyRent is auto-converted via ×12, each line reports both yearlyRent and monthlyRent, apartment types are parsed as free text, and the response includes a mandatory attribution field. This gives the agent operational expectations well beyond the schema.
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 dense but every sentence serves a purpose: core operation, rent-unit behavior, apartment-type handling, attribution requirement, and the PDF alternative. Core functionality is front-loaded in the first sentence, and the rest is operational detail an agent needs to invoke the tool correctly.
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 no output schema, the description does a strong job of explaining what the response contains: per-unit conversions, totals, averages, and attribution. It also covers batching limits, payment-unit conversion, and the sibling tool for PDF export. Nothing essential appears missing for correct use.
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 description adds meaningful semantic detail: it clarifies the yearlyRent/monthlyRent relationship and conversion rule, and it explains that apartmentType free text is interpreted automatically. It does not fully enumerate every property, but the schema already covers those.
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?
Description clearly states the verb and resource: 'Konvertera en hel hyreslista (flera lägenheter) till normhyra i ett anrop.' It specifies the batch scope, the calculation target, and the returned summary, and it explicitly routes PDF creation to export_rent_roll_pdf, distinguishing it from a sibling.
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 gives concrete context: it handles multiple apartments in one call, caps input at 300, and directs users to export_rent_roll_pdf for PDF output. It does not explicitly discuss when to use calculate_normhyra or calculate_actual_rent instead, but the batch-vs-single distinction is implied by 'hel hyreslista' and 'i ett anrop.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Konvertera en hyreslista till normhyra OCH generera en PDF-sammanställning – samma layout som PDF-exporten på normhyra.ai (liggande A4, tabell per lägenhet, sammanfattning). 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.
| Name | Required | Description | Default |
|---|---|---|---|
| apartments | Yes | Lista med lägenheter (max 500 per anrop). | |
| 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?
The description discloses concrete behavioral details beyond the annotations: the PDF layout, the 7-day link validity, the attribution text in the PDF and in every response field, and the instruction to display attribution with results. No contradictions with the 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 front-loaded with the core purpose and layout, followed by return-link details and attribution requirements. Though it repeats the attribution phrase twice, each sentence adds functional information, making it appropriately concise.
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 no output schema, the description adequately covers the return value (download link, validity) and the required attribution field. It also specifies the PDF layout and conversion behavior. The only minor gap is that it doesn't explicitly describe error conditions, but the schema covers input constraints.
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 input schema already provides descriptions for all parameters and properties (100% coverage), including the automatic monthly-to-yearly conversion note for monthlyRent. The tool description adds no parameter-specific semantics beyond what the schema already provides, so baseline 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 clearly states the tool converts a rent list to norm rent and generates a PDF compilation with a specific layout ('liggande A4, tabell per lägenhet, sammanfattning'). It also specifies the return value (download link valid 7 days) and attribution requirements, distinguishing it from calculation-only siblings by focusing on PDF export.
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 implies use when a shareable PDF of a rent roll is needed, mentioning the download link and layout. However, it provides no explicit guidance on when to choose this over sibling tools like calculate_normhyra or calculate_rent_roll, nor any exclusion criteria.
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_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 personal-finance calculators with 2026 tax rules: rent vs buy, leasing, savings, mortgages
Draw buildings as DXF, IFC and 3D, plus exact French rent and charges calculations.
Convert PDF bank statements to checked Excel, CSV or JSON with balance validation.
PDF tools + invoice extraction, bank statement parsing, GST reconciliation & GSTIN validation.
Add one secure layer between your agents and this server.
