Skip to main content
Glama

firma.de Rechner für Gründer

firma.de Schenkungsvertrag-API

schenkungsvertrag
Read-onlyIdempotent

Erstellt einen Schenkungsvertrag nach deutschem Recht aus den festen Bausteinen des Schenkungsvertrag-Generators von firma.de: für Geld (Überweisung oder bar), Fahrzeuge und bewegliche Gegenstände, von einem oder zwei Schenkern; Geld und Gegenstände auch an minderjährige Kinder, Fahrzeuge nur an Volljährige. Die Antwort enthält den Vertragstext (offene Angaben als [Platzhalter]), die Hinweise des Generators (Notar, Minderjährige, Bargeld, Rückforderung), einen Schenkungsteuer-Check je Schenker mit Steuerklasse, Freibetrag und 10-Jahres-Regel (allgemeine Steuerinformation), die Frist für die Anzeige beim Finanzamt und einen Link, der den Entwurf im Generator öffnet: Dort tragen die Beteiligten ihre Namen ein, unterschreiben und laden PDF oder Word herunter. Immobilien und GmbH-Anteile gehen nur beim Notar; dafür gibt es keinen Vertragstext, bei Immobilien aber die Kosten für Notar und Grundbuch. Kostenlos, ohne Schlüssel.

POST mit JSON: flach mit denselben Namen wie bei GET oder verschachtelt wie draft in der Antwort (Schenker unter donors.donor1 und donors.donor2, nie als Liste). Fehlende Felder und null lassen den Standard stehen, "" leert ein Text- oder Datumsfeld. Persönliche Angaben gehen nur hier. format und draft gehen auch im Body.

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

Input Schema

NameRequiredDescriptionDefault
ageNoadult (Standard), under7 (unter 7 Jahren) oder from7 (7 bis 17); auch das Alter in Jahren von 0 bis 130: 0 bis 6 = under7, 7 bis 17 = from7, ab 18 = adult. Ein Geburtsdatum geht vor: Es zählt das Alter am Vertragsdatum, ohne Vertragsdatum das von heute.
vinNoFahrzeug-Identifizierungsnummer (FIN), beim E-Bike die Rahmennummer. Nur per POST im JSON-Body; in einer GET-Adresse antwortet die API mit 400 personalData.
dateNoBei mode=transferred: Tag der Überweisung; bei cashHandover=past: Tag der Übergabe.
ibanNoIBAN des Beschenkten (optional). Nur per POST im JSON-Body; in einer GET-Adresse antwortet die API mit 400 personalData.
itemNo
keysNoAnzahl der Fahrzeugschlüssel.
makeNoMarke des Fahrzeugs.
modeNoBei subject=money: transferred (schon überwiesen, Standard), transferSoon (wird überwiesen, höchstens 30 Tage nach der Unterschrift) oder cash (bar); auch ueberwiesen, wirdueberwiesen, bar.
doneeNo
donorNoName des (ersten) Schenkers. Nur per POST im JSON-Body; in einer GET-Adresse antwortet die API mit 400 personalData.
draftNoEin Link des Generators (…/schenkungsvertrag/#sv=…) oder nur der Teil nach #sv= als Ausgangspunkt; weitere Parameter ändern ihn. In einer GET-Adresse das # als %23 schreiben, sonst kommt der Entwurf nicht an. Ein Link mit persönlichen Angaben geht nur per POST, dort auch ein Entwurf als Objekt, etwa draft aus einer früheren Antwort.
modelNoModell des Fahrzeugs.
moneyNo
placeNoOrt der Unterschrift.
plateNoKennzeichen; beim E-Bike das Versicherungskennzeichen eines S-Pedelecs, bei other ein Kennzeichen der Zulassungsbehörde (dann wie ein zugelassenes Fahrzeug, mit FIN) oder ein Versicherungskennzeichen, etwa eines Mofas. Nur per POST im JSON-Body; in einer GET-Adresse antwortet die API mit 400 personalData.
rightNoNur bei subject=property: none (Standard), niessbrauch oder wohnrecht, das der Schenker behält.
valueNoVerkehrswert des Fahrzeugs oder Gegenstands in ganzen Euro.
amountNoGeldbetrag in Euro, 1 € bis 100.000.000 €.
donor2NoName des zweiten Schenkers; setzt zwei Schenker. Nur per POST im JSON-Body; in einer GET-Adresse antwortet die API mit 400 personalData.
donorsNo
estateNoNur bei marriage=guetergemeinschaft: jointAdmin (gemeinsam verwaltetes Gesamtgut, Standard: beide Ehegatten schenken je zur Hälfte), soleAdmin (der Schenker verwaltet allein, der Ehegatte stimmt zu) oder reserved (Vorbehaltsgut); auch gemeinsam, allein, vorbehaltsgut.
formatNomd (Standard): die Antwort als lesbarer Text mit Link in den Rechner, kurz genug für den Chat. json: alle Werte als JSON.md
clausesNo
custodyNoBei Minderjährigen: joint (beide Eltern, Standard) oder sole (ein Elternteil allein).
dueDateNoBei mode=transferSoon: spätester Tag der Überweisung, höchstens 30 Tage nach der Unterschrift; später ist es ein Versprechen für den Notar (blocked).
mileageNoKilometerstand (optional).
ownHalfNoZwei Schenker außerhalb des Gesamtguts: Die Hälfte des ersten Schenkers stammt aus seinem eigenen Vermögen. Ohne beide Bestätigungen ist der Vertrag nicht vollständig, und der Steuer-Check ist eine grobe Schätzung.
purposeNoNur bei Geld: none (Standard), wish (Verwendungswunsch) oder auflage (verpflichtend). Eine Auflage, eine Wohnung, ein Haus oder ein Grundstück zu kaufen, wird zum Wunsch.
signingNo
specialNonone (Standard: die Schenkung wird jetzt vollzogen), future (erst später versprochen), recurring (regelmäßige Zahlungen), onDeath (erst nach dem Tod), wholeAssets (das ganze Vermögen oder ein Bruchteil) oder mixed (mit Gegenleistung). Alles außer none ist ein Fall für Notar oder Anwalt (blocked).
subjectNoWas verschenkt wird: money (Geld; bargeld setzt zugleich mode=cash), vehicle (Fahrzeug), item (beweglicher Gegenstand), property (Immobilie) oder shares (GmbH-Anteile). property und shares gehen nur beim Notar: Die Antwort kommt dann mit blocked: true und ohne Vertragstext.
vehicleNo
accidentNoBekannte Unfallschäden eines Fahrzeugs mit Zulassung als Text; keine heißt: keine bekannt.
financedNoDas Fahrzeug ist finanziert oder gehört als Sicherheit der Bank: blocked.
handoverNo
itemKindNohousehold (Hausrat), jewelry (Schmuck), preciousMetal (Gold, Silber, Münzen, Edelsteine), art (Kunst), watch (Uhr) oder other (Standard).
marriageNoGüterstand des Schenkers: unknown (Standard), single, zugewinn, guetergemeinschaft oder guetertrennung. Entscheidet über die Zustimmung des Ehegatten und die Anrechnung auf den Zugewinn.
ownHalf2NoWie ownHalf, für den zweiten Schenker.
propertyNo
relationNoWas der Beschenkte für den Schenker ist: spouse, child, stepchild, grandchild, greatGrandchild, parent, grandparent, sibling, nieceNephew, stepParent, childInLaw, parentInLaw, exSpouse, auntUncle, partner oder other; auch deutsch als Bezeichnung des Beschenkten aus Sicht des Schenkers (ehefrau, tochter, sohn, enkel, urenkel, bruder, nichte, schwiegersohn, freundin …). Wörter für den Schenker (oma, vater, tante …) beantwortet die API mit 400 relationDirection: ‚Oma schenkt Enkel‘ heißt relation=grandchild.
zugewinnNonone (Standard), anrechnen oder nichtAnrechnen; nur an den Ehepartner in der Zugewinngemeinschaft.
holderAgeNoBei subject=property mit right: Alter des Berechtigten, bei mehreren des Jüngsten.
relation2NoWas der Beschenkte für den zweiten Schenker ist, Werte wie relation; setzt zwei Schenker.
taxPaidByNodonee (Standard) oder donor: Der Schenker übernimmt die Steuer, die dann als weitere Schenkung mitzählt (§ 10 Abs. 2 ErbStG).
twoDonorsNo
identifierNoSeriennummer, Punze oder Zertifikat des Gegenstands (optional). Nur per POST im JSON-Body; in einer GET-Adresse antwortet die API mit 400 personalData.
priorGiftsNoFrühere Schenkungen des ersten Schenkers an den Beschenkten, für die 10-Jahres-Regel: per GET als YYYY-MM-DD:Wert[:gezahlte Steuer], mehrere mit ; getrennt (2018-03-15:450000:3500); per POST als Liste von { date, value, taxPaid }. Höchstens 5. Wert ist der steuerliche Wert von damals, vor dem Freibetrag.
revocationNoRückforderungsrecht als Liste mit Komma: resale, predecease, insolvency, auflage, divorce (auch verkauf, vorversterben, insolvenz, auflage, scheidung). Nicht für Minderjährige und nicht für eine schon vollzogene Schenkung ohne agreedBeforeExecution.
ausstattungNotrue: Das Geld ist eine Ausstattung (§ 1624 BGB); nur Geld an ein Kind.
pflichtteilNonone (Standard), anrechnen oder nichtAnrechnen; nur wenn der Beschenkte einen Pflichtteil haben kann (Kind, Enkel, Urenkel, Ehepartner, Elternteil).
priorGifts2NoWie priorGifts, für den zweiten Schenker.
signingDateNoDatum der Unterschrift; ohne Angabe heute (Europe/Berlin).
vehicleKindNocar (Standard), motorcycle, camper, ebike oder other.
ausgleichungNonone (Standard), anordnen oder ausschliessen; nur bei Kindern, Enkeln und Urenkeln.
basicSupportNoDer Schenker bezieht Grundsicherungsgeld (früher Bürgergeld), Grundsicherung im Alter, Hilfe zur Pflege oder Sozialhilfe oder wird sie voraussichtlich brauchen; nur für einen Hinweis.
cashHandoverNoBei mode=cash: atSigning (bei der Unterschrift, Standard) oder past (schon früher, Tag in date).
deregisteredNoDas Fahrzeug ist abgemeldet (außer Betrieb gesetzt); nur bei car, motorcycle und camper.
doneeAddressNoAnschrift des Beschenkten in einer Zeile. Nur per POST im JSON-Body; in einer GET-Adresse antwortet die API mit 400 personalData.
donorAddressNoAnschrift des Schenkers in einer Zeile. Nur per POST im JSON-Body; in einer GET-Adresse antwortet die API mit 400 personalData.
handoverDateNoBei handover=past: Tag der Übergabe.
handoverTimeNoUhrzeit der Übergabe als HH:MM (optional).
purposeLabelNoDer Zweck in wenigen Worten, etwa Studium. Nennt er den Erlass eines Darlehens, ist die Antwort gesperrt (subjectNotCovered): Den deckt die API noch nicht ab.
donor2AddressNoAnschrift des zweiten Schenkers. Nur per POST im JSON-Body; in einer GET-Adresse antwortet die API mit 400 personalData.
propertyValueNoNur bei subject=property: Verkehrswert der Immobilie in ganzen Euro; damit nennt die Antwort die Kosten für Notar und Grundbuch.
spouseConsentNoZustimmung des Ehegatten des Schenkers: per GET true oder false (die Zeile mit leerem Namen), per POST sein Name. Name: Nur per POST im JSON-Body; in einer GET-Adresse antwortet die API mit 400 personalData.
doneeBirthDateNoGeburtsdatum des Beschenkten, ab 1900; bei Minderjährigen nötig; es bestimmt das Alter am Vertragsdatum, ohne Vertragsdatum am heutigen Tag. Nur per POST im JSON-Body; in einer GET-Adresse antwortet die API mit 400 personalData.
donorBirthDateNoGeburtsdatum des Schenkers (optional), ab 1900. Nur per POST im JSON-Body; in einer GET-Adresse antwortet die API mit 400 personalData.
parentDeceasedNoNur bei relation=grandchild: Der Elternteil des Enkels, also das Kind des Schenkers, ist vor der Schenkung gestorben; dann gilt der Freibetrag eines Kindes.
toDoneeAccountNoDas Geld geht auf ein Konto des Beschenkten (Standard true); bei Minderjährigen auf ein Konto auf den Namen des Kindes, dann Pflicht.
donor2BirthDateNoGeburtsdatum des zweiten Schenkers (optional), ab 1900. Nur per POST im JSON-Body; in einer GET-Adresse antwortet die API mit 400 personalData.
purposeDeadlineNoBei purpose=auflage: bis wann das Geld verwendet wird (optional).
relationChangedNoDas Verhältnis hat sich seit einer früheren Schenkung geändert, etwa durch Heirat: Der Steuer-Check ist dann eine grobe Schätzung.
representative1NoBei Minderjährigen: der gesetzliche Vertreter. donor1 oder donor2 verknüpft einen Schenker, der Elternteil ist (geht per GET); ein Name nur per POST.
representative2NoWie representative1, für den zweiten Elternteil bei gemeinsamem Sorgerecht.
firstRegistrationNoErstzulassung als Datum, ab 1900 (optional).
agreedBeforeExecutionNoBei einer schon vollzogenen Schenkung (transferred, cashHandover=past, handover=past): Die Vereinbarungen wurden vorher getroffen. Nur dann bleiben Rückforderungsrecht, Auflage und Anrechnungen stehen, und der Vertrag hält das fest.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already mark this as read-only, idempotent and non-destructive, and the description adds substantive behavior: the exact response contents (contract text with [Platzhalter], generator notes, per-donor tax check with Steuerklasse/Freibetrag/10-Jahres-Regel, filing deadline, draft link), the blocked outcome for property and shares, and the 400 personalData failure mode for GET with personal fields. Default handling for missing fields, null and empty string is also disclosed, which goes well beyond 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense paragraphs that are front-loaded with what is produced and what is out of scope, then the POST shape, then endpoints. Every sentence carries information given 76 parameters, though the first sentence is long and clause-heavy, and the draft-link mechanics are only fully explained in the schema.

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 76-parameter, 0-required generation tool with no output schema, the description carries the necessary weight: it describes the response payload in detail, the alternatives (POST vs GET for personal data), and the blocked/error outcomes. Nothing an agent needs to call or interpret the tool correctly appears to be 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 87%, so per-parameter meanings are largely documented already, setting the baseline at 3. The description still adds non-obvious structural semantics the schema cannot express per-field: flat keys matching GET names or nesting under donors.donor1/donor2 (never a list), that missing/null preserves defaults while "" clears a text or date field, and that format and draft are accepted in the body.

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 opening sentence gives a specific verb and resource ('Erstellt einen Schenkungsvertrag nach deutschem Recht') and immediately scopes it to fixed generator building blocks, naming the covered subjects (Geld, Fahrzeuge, bewegliche Gegenstände), the donor count, and what is explicitly excluded (Immobilien und GmbH-Anteile nur beim Notar). An agent can distinguish this from siblings like darlehensvertrag or quittung without opening the 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?

It states clear inclusion/exclusion rules: money and items may go to minors, vehicles only to adults, property and shares are notary-only and yield no contract text. It also states the tool is free and needs no key, and that personal data must be sent via POST. It stops short of explicitly naming sibling tools as alternatives, so routing is inferable rather than spelled out.

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