Skip to main content
Glama

FrankKi

by app.frankki
OverviewDiscussionsAdmin

Versandpreis ermitteln

shipping_quote
Read-only

Registered-mail availability depends on the destination and its current catalog, not a Germany-only rule. The codes einschreiben_einwurf and einschreiben_uebergabe are German products; Switzerland uses ch_einschreiben. For other destinations, use only methods returned in availableDeliveryTypes by a standard shipping_quote for that country, then quote the chosen code. A rejected country/method pair does not establish availability in other countries. A catalog snapshot with no registered method does not prove that the postal service never offers one. Tracked mail is not registered mail. Never substitute standard or tracked delivery when registered mail was requested without the user's agreement. A carrier-issued proof-of-posting PDF is not promised. Reply in the user's conversation language, regardless of recipient country, letter language, German tool titles or bilingual tool results. Translate shipping methods, letter formats, delivery estimates and explanations for the user. In English: Standardbrief = standard letter; Kompaktbrief = compact letter; Großbrief = large letter; Maxibrief = maxi letter; Einschreiben = registered mail; Einwurf-Einschreiben = registered mail with recorded mailbox delivery; Übergabe-Einschreiben = registered mail with signature on delivery; Einlieferungsbeleg = proof of posting. Use localized money and number formatting. Keep tool names, parameter names, deliveryType values and error codes unchanged in tool calls; show codes to users only when needed for troubleshooting. This presentation rule does not translate the letter's contents. Ermittelt den Preis, das Briefformat, die Versandart und die voraussichtliche Laufzeit für einen geplanten Brief, bevor er versendet wird. Das ist die Schätzung für den Fall, dass der Brief erst geplant ist: du gibst nur Seitenzahl, Land und Versandart an. Steht der Brief schon fest, versendest du ihn mit order_send (order_send mit dryRun:true liefert dann den genaueren Preis für genau diesen Brief). Der Preis gilt pro Brief und enthält bereits die Mengenstaffel des Partners, falls eine greift (Feld tierId). Für die Staffelpreise selbst nutze pricing_tiers. EN: Determines the price, letter format, shipping method and estimated delivery time for a planned letter, before it is sent. This is the estimate for when the letter is still only planned: you only supply page count, country and delivery type. Once the letter exists, order_send performs the actual send (and order_send with dryRun:true gives the more precise price for that specific letter). The price is per letter and already includes the partner's volume tier where one applies (field tierId). For the volume tiers themselves, call pricing_tiers.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
colorYesFarbannahme fuer eine allgemeine Schaetzung. Mit letterId erkennt FrankKi die Farbe aus der gespeicherten Vorschau und ignoriert diesen Wert. EN: Colour assumption for a general estimate. With letterId, FrankKi detects colour from the stored preview and ignores this value.
countryNoISO 3166-1 alpha-2, Standard DE. EN: ISO 3166-1 alpha-2, defaults to DE.
expressNo
letterIdNoOptional: die letterId eines bestehenden Entwurfs. Dann kommen Seitenzahl und Farbe aus der gespeicherten Vorschau; fuer den endgueltigen Preis inklusive Anhaengen nutze order_send mit dryRun:true. EN: Optional: the letterId of an existing draft. Page count and colour then come from the stored preview; for the final price including attachments, use order_send with dryRun:true.
pageCountYesSeitenzahl fuer eine allgemeine Schaetzung. Mit letterId verwendet FrankKi die gespeicherte Seitenzahl und ignoriert diesen Wert. EN: Page count for a general estimate. With letterId, FrankKi uses the stored page count and ignores this value.
reasoningNo
deliveryTypeYesRegistered-mail availability depends on the destination and its current catalog, not a Germany-only rule. The codes einschreiben_einwurf and einschreiben_uebergabe are German products; Switzerland uses ch_einschreiben. For other destinations, use only methods returned in availableDeliveryTypes by a standard shipping_quote for that country, then quote the chosen code. A rejected country/method pair does not establish availability in other countries. A catalog snapshot with no registered method does not prove that the postal service never offers one. Tracked mail is not registered mail. Never substitute standard or tracked delivery when registered mail was requested without the user's agreement. A carrier-issued proof-of-posting PDF is not promised.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / deliveryType / description
      Added value: +"Registered-mail availability depends on the destination and its current catalog, not a Germany-only rule. The codes einschreiben_einwurf and einschreiben_uebergabe are German products; Switzerland uses ch_einschreiben. For other destinations, use only methods returned in availableDeliveryTypes by a standard shipping_quote for that country, then quote the chosen code. A rejected country/method pair does not establish availability in other countries. A catalog snapshot with no registered method does not prove that the postal service never offers one. Tracked mail is not registered mail. Never substitute standard or tracked delivery when registered mail was requested without the user's agreement. A carrier-issued proof-of-posting PDF is not promised."
    • 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"
+]
  2. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already establish readOnlyHint=true and destructiveHint=false. The description adds real context beyond that: the price is per letter and already includes the partner's volume tier (field tierId), and a carrier proof-of-posting PDF is not promised. It doesn't cover rate limits or response shape, but for a read-only quote that's minor.

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 definition opens with roughly fifteen sentences of registered-mail policy and translation rules that are not front-loaded toward the tool's function and substantially duplicate the deliveryType parameter description. The actual purpose ('Ermittelt den Preis...') appears only at the very end, in both German and English, doubling length again.

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

Completeness4/5

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

For a read-only quote with no output schema, the description covers what matters: pricing behavior, tier inclusion, how it differs from order_send, and even the intelligence not to substitute tracked for registered mail. Only minor gaps remain (no mention of response fields beyond tierId, no error behavior).

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

Parameters3/5

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

Schema coverage is 71% and the deliveryType parameter description repeats the registered-mail policy text verbatim, so the description adds little for that field. It does clarify the letterId/pageCount/color interplay (letterId overrides the estimate values and order_send dryRun is needed for the final price incl. attachments), which is useful, but most parameter meaning already lives in the schema.

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 German/English core states a specific verb and resources: determines price, letter format, shipping method and estimated delivery time for a planned letter. It also distinguishes itself from order_send (actual send, or dryRun for the precise price) and pricing_tiers. However, this purpose statement is buried at the end of a long preamble, so the agent must read past policy text to find it.

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

Usage Guidelines5/5

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

Explicit routing: use this when the letter is only planned and you supply page count, country and delivery type; once the letter exists use order_send, and order_send with dryRun:true gives the exact price. It also names pricing_tiers for the tier tables themselves and explains registered-mail availability rules per destination.

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

All FrankKi toolsInspect
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.

Resources