Skip to main content
Glama

FrankKi

by app.frankki
OverviewDiscussionsAdmin

Briefe im Stapel versenden

order_send_batch
Destructive

Reicht mehrere Briefe als einen Stapel ein. Jeder Eintrag wird einzeln geprüft und bepreist. Der Stapel landet als eine Freigabe für alle Empfänger in der Warteschlange. Gib dem Menschen immer den zurückgegebenen approvalUrl, damit er Empfängerliste, Anzahl und Gesamtkosten im angemeldeten Portal prüfen und dort entscheiden kann. Nur eine OAuth-Verbindung mit der ausdrücklich erteilten Berechtigung approval:self_approve darf selbst freigeben. Bei Ablehnung wird die gesamte Reservierung zurückgebucht. Mit dryRun bleibt es bei einer kostenfreien Probe. EN: Submits several letters as one batch. Each item is checked and priced separately. The batch enters the approval queue as one approval covering every recipient. Always give the human the returned approvalUrl so they can review the recipient list, count and total cost in the signed-in portal and decide there. Only an OAuth connection explicitly granted approval:self_approve may approve on its own. Rejection refunds the entire reservation. With dryRun, it remains a free rehearsal.

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.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Adds rich context beyond the destructiveHint=true annotation: batch enters a single approval queue covering all recipients, rejection refunds the entire reservation, only connections with approval:self_approve may self-approve, and dryRun validates without charging. This is exactly the workflow and auth detail an agent needs.

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 content is valuable but the description is long and duplicated in German and English (EN:), roughly doubling its length. Front-loaded with the core action, but the bilingual repetition is not strictly necessary for every sentence.

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 mutation tool with no output schema, the description covers the full lifecycle: submission, per-item pricing, approval queue behavior, human review via approvalUrl, self-approval permission requirement, refund on rejection, and dryRun behavior. Nothing critical is 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 100%, so baseline is 3. The description adds meaning beyond the schema by clarifying batch-level semantics (one approval covering every recipient, single reservation) and the dryRun mode, though it doesn't add per-parameter syntax detail.

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?

States a specific verb+resource+scope: submitting several letters as one batch, with per-entry validation and pricing. This clearly distinguishes it from the single-item sibling order_send.

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?

Explicitly tells the agent to always hand the returned approvalUrl to the human for review, and states the OAuth permission condition (approval:self_approve) required for self-approval. It also notes dryRun for a free rehearsal, covering when-not-to-charge.

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