Skip to main content
Glama

FrankKi

by app.frankki

Briefe im Stapel versenden

order_send_batch
Destructive

Versendet mehrere Briefe in einem Stapel. Jeder Eintrag wird einzeln geprüft, bepreist und versendet; ein fehlerhafter Eintrag lässt den Rest des Stapels weiterlaufen (mit stopOnError hält der Stapel dort an). Der ganze Stapel wird als EINE einzige Freigabe für alle Empfänger zusammen eingereicht: der Mensch sieht die Empfängerliste, die Anzahl und die Gesamtkosten und entscheidet mit einem approval_decide über alles. Bei Freigabe gehen alle Einträge raus, bei Ablehnung wird die gesamte Reservierung zurückgebucht. Mit dryRun bleibt es bei der Probe: kostenfrei, und die Briefe bleiben liegen. EN: Sends several letters in one batch. Each entry is checked, priced and sent individually; a failing entry lets the rest of the batch continue (with stopOnError the batch stops there). The whole batch is submitted as ONE single approval covering every recipient: the human sees the recipient list, the count and the total cost and decides on all of it with a single approval_decide. On approval every entry goes out, on rejection the entire reservation is refunded. With dryRun it stays a rehearsal: free of charge, and the letters stay put.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemsYesListe der Briefe im Stapel. Jeder Eintrag traegt seinen eigenen clientOrderId und genau eine Quelle: eine letterId ODER einen inline Brief. EN: List of letters in the batch. Each entry carries its own clientOrderId and exactly one source: a letterId OR an inline letter.
dryRunNoSimuliert den ganzen Stapel: prueft jeden Eintrag, berechnet aber nichts und versendet nichts. EN: Simulates the whole batch: validates each entry but charges nothing and sends nothing.
presetNameNoOptionales Preset fuer den ganzen Stapel; pro Eintrag ueberschreibbar ist nicht vorgesehen. EN: Optional preset for the whole batch; per-entry override is not supported.
stopOnErrorNoBricht den Stapel beim ersten Fehler ab. Standard false. EN: Aborts the batch on the first error. Default false.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only say destructiveHint=true, but the description goes much further: it explains per-item validation and pricing, failure continuation, stopOnError, one combined approval, full send on approval, refund on rejection, and dryRun behavior. This is rich, accurate behavioral disclosure 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.

Conciseness3/5

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

The description is front-loaded and contains useful detail, but it is long because every point is repeated in both German and English. It could be more concise with one language or structured bullets without losing meaning.

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 batch-send tool, the description covers the key operational context: approval flow, error behavior, cost implications, dryRun, and side effects. No output schema exists, but the description provides enough for an agent to invoke the tool correctly and understand what will happen.

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 value by connecting items, dryRun, and stopOnError to the actual batch execution model and approval semantics, which the schema alone does not convey.

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 clearly states a specific verb and resource: sending multiple letters as one batch. It also distinguishes itself from single-send siblings by emphasizing the batch, the single approval, and options like stopOnError and dryRun.

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 makes the batch context and approval flow clear, so an agent can infer when to use it. However, it never explicitly says when to prefer this over order_send, shipping_quote, or other related tools, nor does it state exclusions or alternatives.

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.2/5.0
Disambiguation2/5

The surface contains multiple clusters whose boundaries are unclear: letterhead_list/letter_design_list/brand_kit_get/profile_get all expose similar letterhead/brand data, and letter_preview/template_preview/letter_design_preview are easy to confuse. The many *_app variants (approval_decide_app, template_decide_app, status/page-url helpers) further duplicate core actions. Rich descriptions help, but with 72 tools an agent will frequently pick the wrong member of a cluster.

Naming Consistency3/5

Most tools follow a readable snake_case resource_action pattern (address_upsert, approval_list, letter_schedule, wallet_balance). However, there are notable exceptions like analytics_summary, mcp_health, pricing_tiers, shipping_quote and order_einlieferungsbeleg, plus German/English mixing and semantically competing prefixes (letterhead_ vs letter_design_ vs brand_kit_). The style is not chaotic, but it is not uniformly consistent.

Tool Count1/5

With 72 tools this is an extreme mismatch for an MCP surface. The count is inflated by app-card-only helpers, separate preview variants and overlapping design/letterhead/brand tools that could be consolidated. Even a complex domain like postal letters does not justify this many top-level entry points.

Completeness4/5

The core domain is very well covered: addresses, letters, documents, templates, approvals, sender profiles, wallet, scheduling, archive exports and analytics all have lifecycle operations. The main gaps are minor workarounds rather than dead ends: no delete for addresses or documents, no attachment listing/deletion, and letter corrections are handled by creating a new draft.

Resources