Skip to main content
Glama

FrankKi

by app.frankki
OverviewDiscussionsAdmin

Versandpreis ermitteln

shipping_quote
Read-only

Registered-mail availability follows the destination's current catalog. The codes einschreiben_einwurf and einschreiben_uebergabe are German products; Switzerland uses ch_einschreiben. For other destinations, use methods returned in availableDeliveryTypes by a standard shipping_quote for that country, then quote the chosen code. A rejected country/method pair gives a verdict for that pair alone. A catalog snapshot gives a verdict for that snapshot alone. Tracked mail and registered mail are distinct products. Get the user's agreement before switching a requested registered method to standard or tracked delivery. Promise a carrier-issued proof-of-posting PDF only after confirming one is available. 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. Preserve the letter's contents in its original language. 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 follows the destination's current catalog. The codes einschreiben_einwurf and einschreiben_uebergabe are German products; Switzerland uses ch_einschreiben. For other destinations, use methods returned in availableDeliveryTypes by a standard shipping_quote for that country, then quote the chosen code. A rejected country/method pair gives a verdict for that pair alone. A catalog snapshot gives a verdict for that snapshot alone. Tracked mail and registered mail are distinct products. Get the user's agreement before switching a requested registered method to standard or tracked delivery. Promise a carrier-issued proof-of-posting PDF only after confirming one is available.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / deliveryType / description
      Previous 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."New value: +"Registered-mail availability follows the destination's current catalog. The codes einschreiben_einwurf and einschreiben_uebergabe are German products; Switzerland uses ch_einschreiben. For other destinations, use methods returned in availableDeliveryTypes by a standard shipping_quote for that country, then quote the chosen code. A rejected country/method pair gives a verdict for that pair alone. A catalog snapshot gives a verdict for that snapshot alone. Tracked mail and registered mail are distinct products. Get the user's agreement before switching a requested registered method to standard or tracked delivery. Promise a carrier-issued proof-of-posting PDF only after confirming one is available."
  2. 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"
+]
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly/destructive annotations, the description discloses substantial behavioral rules: registered-mail availability follows the destination catalog, product codes are country-specific, a rejected country/method pair or catalog snapshot yields a verdict for that pair/snapshot alone, tracked and registered mail are distinct, and user agreement is required before downgrading a registered method. It also warns not to promise a proof-of-posting PDF until confirmed available.

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

Conciseness3/5

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

The purpose statement is buried after a long block of delivery-method rules, and the text repeats the deliveryType schema content plus an extensive bilingual translation glossary that is verbose relative to the task. Content is mostly relevant but not front-loaded and includes redundancy, so structure is only adequate.

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?

There is no output schema, and the description covers the result shape reasonably (price, letter format, shipping method, delivery time, tierId, availableDeliveryTypes) along with safety and scoping caveats. It stops short of describing response fields or pagination/format details, but is largely complete for a read-only quoting tool.

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?

With 71% schema coverage the description still adds value: it tells the agent which inputs characterize a planned estimate (page count, country, delivery type) and explains the country-specific deliveryType codes (einschreiben_einwurf/uebergabe are German, ch_einschreiben for Switzerland), plus the tierId pricing behavior. It says 'you only supply page count, country and delivery type', which slightly mismatches the required set (color is required, country defaults to DE), but the delivery-code guidance compensates.

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 English sentence explicitly states the verb and outputs: 'Determines the price, letter format, shipping method and estimated delivery time for a planned letter, before it is sent.' It also distinguishes itself from siblings by naming order_send (actual send, dryRun for precise price) and pricing_tiers (the tiers themselves).

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?

Gives explicit when-to-use conditions ('when the letter is still only planned: you only supply page count, country and delivery type') and routes to the right alternative once the letter exists ('order_send with dryRun:true gives the more precise price'). It also names pricing_tiers for the tier data, so alternatives and exclusions are covered.

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