FrankKi

Versand planen

letter_schedule

Plant den Versand eines bestehenden Entwurfs für einen späteren Zeitpunkt (fester Termin, relative Verzögerung oder wiederkehrend per cron). Alle Prüfungen und der Preis werden sofort ermittelt und die Kosten reserviert. Eine echte OAuth-Verbindung legt zuerst eine Freigabe an. Die eingebettete Karte ist Vorschau und Freigabe. Nach ihrer Anzeige reicht im Chat eine kurze Bestätigung; PDF-Link und Brieftext gehören in reine Textansichten. Eine OAuth-Verbindung mit approval:self_approve darf über die Karte entscheiden. Nach der Freigabe entsteht die Planung, der eigentliche Versand läuft zum geplanten Zeitpunkt durch dieselbe Versandpipeline. EN: Schedules an existing draft for a later time (fixed date, relative delay or recurring via cron). All checks and the price are determined immediately and the cost is reserved. A real OAuth connection creates an approval first. The embedded card is the preview and approval. Once it appears, a short chat confirmation is enough; PDF links and letter text belong in text-only views. An OAuth connection with approval:self_approve may decide through the card. Approval creates the schedule, and the actual send runs at the planned time through the same send pipeline.

Input Schema

TableJSON Schema

Name	Required	Description
`mode`	Yes	at = fester Zeitpunkt, in = relative Verzögerung, cron = wiederkehrend. EN: at = fixed time, in = relative delay, cron = recurring.
`color`	No
`delay`	No	Verzögerung bei mode='in': '2d', '1w', '3h', 'next-business-day', 'next-monday', 'end-of-month'. EN: Delay for mode='in': '2d', '1w', '3h', 'next-business-day', 'next-monday', 'end-of-month'.
`dryRun`	No	Prüft und bepreist die Planung, legt aber nichts an und reserviert nichts. Liefert dryRunWouldHaveCost. EN: Validates and prices the schedule but creates nothing and reserves nothing. Returns dryRunWouldHaveCost.
`sendAt`	No	Zeitpunkt bei mode='at' (ISO 8601, Berlin-Zeit wenn ohne Offset). EN: Time for mode='at' (ISO 8601, Berlin time if no offset).
`endDate`	No	Enddatum für eine cron-Serie. EN: End date for a cron series.
`express`	No
`auditTag`	No
`letterId`	Yes	Bestehender Entwurf, der geplant versendet wird. EN: Existing draft to be sent on schedule.
`reasoning`	No
`presetName`	No
`templateId`	No
`signatureId`	No
`deliveryType`	No
`maxCostEuros`	No	Maximalbetrag in Euro. Liegt der Preis darüber, wird abgebrochen. EN: Maximum amount in euros. If the price is above it, the call is aborted.
`cronExpression`	No	5-Felder cron bei mode='cron': 'min std tag monat wochentag'. EN: 5-field cron for mode='cron': 'min hour day month weekday'.
`sendBeforeHour`	No	Versand-Cutoff in Berliner Ortszeit. Nach dieser Stunde wird auf den nächsten Werktag verschoben. EN: Send cutoff in Berlin local time. After this hour it shifts to the next business day.
`mandantennummer`	No
`senderAddressId`	No
`senderProfileId`	No
`businessDaysOnly`	No	Nur an Werktagen versenden, sonst auf den nächsten Werktag verschieben. Standard true. EN: Send on business days only, otherwise shift to the next business day. Default true.
`includeSignature`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 13, 2026

changedInput schema / properties / deliveryType / enum

Previous value: -[
-  "standard",
-  "einschreiben_einwurf",
-  "einschreiben_uebergabe"
-]New value: +[
+  "standard",
+  "einschreiben_einwurf",
+  "einschreiben_uebergabe",
+  "ch_b_post",
+  "ch_a_post",
+  "ch_einschreiben",
+  "at_eco",
+  "at_prio",
+  "intl_standard",
+  "intl_priority",
+  "intl_express",
+  "intl_tracked",
+  "intl_registered"
+]

First observedAug 8, 2026

TDQS

B3.2/5.0

Behavior4/5

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

Annotations only declare a non-destructive write, so the description carries most of the burden and delivers: checks and pricing run immediately, cost is reserved, a real OAuth connection creates an approval first, approval is what actually creates the schedule, and the send later flows through the same send pipeline. This is real behavioral context, though reversibility of the reservation is not addressed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

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

The first sentence is well front-loaded, but the content is then duplicated wholesale in German and English, and several sentences address the UI/chat presentation flow ('kurze Bestätigung', 'PDF-Link und Brieftext gehören in reine Textansichten') rather than how to invoke the tool. Much of the text does not earn its place.

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

Completeness3/5

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

For a 22-parameter mutation tool with no output schema, the description gives a solid operational narrative (pricing, reservation, approval gating) but leaves the majority of parameters undocumented and never explains the returned cost/approval artifacts. Adequate at the workflow level, incomplete at the call-construction level.

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

Parameters2/5

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

Schema description coverage is only 45%, so the description should compensate — but it only restates the mode enum values (fixed/relative/cron) that the schema already documents. Roughly a dozen parameters (color, express, auditTag, reasoning, presetName, templateId, signatureId, deliveryType, mandantennummer, senderAddressId, senderProfileId, includeSignature) are explained in neither the schema nor the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb and resource ('Schedules an existing draft for a later time') plus the three timing modes, which clearly contrasts with an immediate-send tool. It stops short of naming any sibling (e.g. order_send, schedule_list_or_cancel), so differentiation must be inferred from the verb alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description walks through the scheduling/approval workflow, which implies when this tool is appropriate, but it never states when NOT to use it or which alternative to reach for (immediate send vs. listing/cancelling). Usage is inferable rather than explicit.

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

All FrankKi tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Versand planen

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources