Skip to main content
Glama

firma.de Rechner für Gründer

Einkommensteuer-Rechner API

einkommensteuer
Read-onlyIdempotent

Rechnet für Selbstständige und Gründer vom Gewinn aus alles, was im Jahr an Steuern anfällt, mit derselben Engine wie der Einkommensteuer-Rechner von firma.de: Einkommensteuer nach dem Tarif des § 32a EStG (Grund- oder Splittingtabelle), Solidaritätszuschlag, Kirchensteuer und für Gewerbetreibende die Gewerbesteuer mit ihrer Anrechnung nach § 35 EStG. Dazu Kranken- und Pflegeversicherung als freiwillig gesetzlich Versicherte, die Günstigerprüfung zwischen Kindergeld und Kinderfreibeträgen, der Rechenweg bis zum zu versteuernden Einkommen, Durchschnitts- und Grenzsteuersatz, die Vorauszahlungen mit Terminen, was du monatlich zurücklegen kannst, Hinweise zum Fall und ein Link, der die Berechnung im Rechner öffnet. Jahre 2025, 2026, 2027; 2027 rechnet mit dem Regierungsentwurf, der noch nicht beschlossen ist. Eine unverbindliche Schätzung, allgemeine Steuerinformation, keine Steuerberatung. Kostenlos, ohne Schlüssel.

POST mit JSON: die Felder flach wie bei GET oder unter values, etwa { "year": 2026, "values": { "profit": 60000, "filing": "joint" } }. So passt auch input aus einer früheren Antwort: die Felder von input unverändert. Fehlende Felder und null behalten den Standard des Rechners. format geht auch hier, ebenso ?format=md in der Adresse.

Antwortet auf Deutsch, als Text oder JSON. Der Rechner für Menschen: https://www.firma.de/einkommensteuer/ – REST: https://www.firma.de/api/einkommensteuer/

Input Schema

NameRequiredDescriptionDefault
landNoNur bei church=true: Bundesland für den Kirchensteuersatz, 8 % in Bayern und Baden-Württemberg, sonst 9 %; Kürzel wie by, Name wie Bayern oder NRW. Ohne Angabe 9 %.
yearNoSteuerjahr: 2025, 2026, 2027. Standard 2026. 2027 rechnet mit dem Regierungsentwurf, der noch nicht beschlossen ist.
churchNoKirchensteuerpflichtig (bei filing=joint beide). Standard false.
filingNoVeranlagung: single (Einzelveranlagung, Grundtabelle; Standard) oder joint (Zusammenveranlagung von Ehe- oder eingetragenen Lebenspartnern, Splittingtabelle).single
formatNomd (Standard): die Antwort als lesbarer Text mit Link in den Rechner, kurz genug für den Chat. json: alle Werte als JSON.md
healthNoKrankenversicherung: gkv (freiwillig gesetzlich versichert; Standard), pkv (privat, mit pkvMonthly) oder none (keine Beiträge hier, etwa familienversichert oder über eine Anstellung).gkv
profitNoGewinn aus der Selbstständigkeit im Jahr in ganzen Euro (Einnahmen minus Betriebsausgaben), vor Gewerbesteuer; negativ bei Verlust. Standard 60.000.
valuesNoNur POST: die Felder als Objekt, statt sie flach zu schreiben.
pensionNoAltersvorsorge im Jahr (gesetzliche Rentenversicherung, Versorgungswerk, Rürup) in ganzen Euro; abziehbar bis zum Höchstbetrag (2026: 30.826 €, bei filing=joint doppelt). Standard 0.
sickPayNoNur bei health=gkv: mit Anspruch auf Krankengeld (allgemeiner Beitragssatz 14,6 % statt ermäßigt 14,0 %). Standard false.
activityNoTätigkeit: freiberuflich (§ 18 EStG, keine Gewerbesteuer; Standard) oder gewerblich (§ 15 EStG, mit Gewerbesteuer und ihrer Anrechnung nach § 35 EStG).freiberuflich
childrenNoKinder mit Kindergeld, 0 bis 10. Die Berechnung prüft je Kind, ob Kindergeld oder Kinderfreibeträge günstiger sind. Standard 0.
hebesatzNoNur bei activity=gewerblich: Hebesatz der Gemeinde für die Gewerbesteuer in Prozent, ganze Zahl von 200 bis 1000, etwa 490 für München. Standard 400.
extraRateNoNur bei health=gkv: Zusatzbeitrag deiner Kasse in Prozent, 0 bis 5. Ohne Angabe der durchschnittliche Zusatzbeitrag des Jahres (2026: 2,9 %).
pkvMonthlyNoNur bei health=pkv: Beitrag für die Basisabsicherung samt Pflegeversicherung im Monat in ganzen Euro, laut Bescheinigung der Versicherung. Standard 600.
otherIncomeNoWeitere eigene Einkünfte im Jahr nach Werbungskosten, etwa Arbeitslohn oder Vermietung, in ganzen Euro; darf negativ sein. Bei health=gkv zählen positive Einkünfte auch für die Beitragsbemessung, ein Verlust mindert sie nicht. Einbehaltene Lohnsteuer rechnet die API nicht an. Standard 0.
singleParentNoNur bei filing=single mit children ab 1: alleinerziehend, mit dem Entlastungsbetrag nach § 24b EStG. Standard false.
partnerIncomeNoNur bei filing=joint: Einkünfte des Partners im Jahr nach Werbungskosten in ganzen Euro; darf negativ sein. Standard 0.
otherDeductionsNoAbziehbare Sonderausgaben im Jahr in ganzen Euro, etwa Spenden, gezahlte Kirchensteuer oder 80 % der Kinderbetreuungskosten; außergewöhnliche Belastungen nur mit dem Teil über der zumutbaren Belastung. Abgezogen wie angegeben, darunter zählt der Pauschbetrag (36 €, bei filing=joint doppelt). Standard 0.
partnerDeductionsNoNur bei filing=joint: abziehbare Vorsorgeaufwendungen des Partners im Jahr in ganzen Euro (Renten- und Pflegebeitrag, Krankenbeitrag ohne den Anteil für das Krankengeld); abgezogen wie angegeben. Standard 0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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 readOnlyHint, idempotentHint, and no destructive effects. The description adds valuable context beyond that: it is an estimate, not tax advice, the 2027 calculation is based on a draft bill, and it is free without an API key. It could mention error handling or performance, but the added behavioral context is solid.

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?

The description is front-loaded with the core purpose and is dense for a 20-parameter tool, which is justified. It does repeat the 2027 draft caveat (also present in the year parameter schema) and could be more skimmable with structure, but there is little pure filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tax calculator with no output schema, the description covers purpose, calculation scope, output components (Rechenweg, Durchschnitts-/Grenzsteuersatz, Vorauszahlungen, monthly savings recommendation, link), input format, years, legal disclaimer, and access model. Nothing essential for correct invocation is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful usage detail: POST bodies can place fields flat or under a 'values' object, missing/null fields keep defaults, and input from a prior response can be passed unchanged. That goes beyond the per-parameter schema descriptions.

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?

The description uses a specific verb ('Rechnet') and resource ('Einkommensteuer', 'Solidaritätszuschlag', 'Gewerbesteuer') and scopes it to 'Selbstständige und Gründer'. It names the exact calculation engine and enumerates the tax components, making the tool's function unmistakable.

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?

It clearly states the target audience (self-employed and founders), the supported years, and that the tool is free and keyless. However, it does not explicitly compare to siblings like gmbh_steuern or state when not to use it, leaving a small gap in routing guidance.

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.

Resources