ONYST RVG

Berechnungsbogen erzeugen

rvg_create_calculation_sheet

Erzeugt einen Berechnungsbogen als PDF: die Herleitung einer Berechnung, keine Rechnung. Rufe es, wenn nur die Herleitung als Datei gebraucht wird. Zählt als eine Anfrage, nicht als Rechnung; ohne den Tarif ONYST RVG im Standardlayout ohne Logo. Für eine abrechenbare Rechnung rvg_create_invoice; braucht der Nutzer keine Datei, genügt rvg_calculate. Der Download-Link ist mehrfach abrufbar und liefert jedes Mal denselben Bogen (die Antwort nennt, bis wann und wie oft). Gibt dein Host Dateien an den Nutzer weiter (etwa Claude Code oder claude.ai), nimm delivery: file (neben request) — dann hängt der Bogen als Datei an. Zeigt dein Host Ansichten, erscheint der Link dort als Karte mit „Öffnen“ — verweise dann auf die Karte, statt den Link in deine Antwort zu schreiben; ohne Ansicht gib ihn unverändert weiter.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "request": "<request>"
    },
    "name": "rvg_create_calculation_sheet"
  }
}

Input Schema

Name	Required	Description	Default
`request`	Yes	Die Angelegenheit wie bei rvg_calculate.
`delivery`	No	Wie das Dokument ankommt (eigenes Argument neben request, nicht darin): link (Vorgabe) gibt einen Download-Link für den Menschen im Chat; file stellt sofort aus und hängt die Datei zusätzlich als Ressource an — für Hosts, die Dateien an den Nutzer weitergeben (etwa Claude Code und claude.ai); sonst link, etwa in ChatGPT. Gezählt wird in beiden Fällen einmal.

Output Schema

Name	Required	Description	Default
`hinweis`	Yes
`downloadUrl`	Yes
`expiresAtUtc`	Yes
`maxDownloads`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 8, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations only declare the write/non-destructive/openWorld profile, and the description adds real context beyond that: the call counts as one request but not as an invoice, defaults to the standard layout without logo absent the ONYST RVG tariff, and the download link is idempotent with a stated validity window in the response. It stops short of saying whether a previously generated sheet can be replaced or deleted, or what happens on regeneration, but the safety-relevant behavior is well covered.

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

Conciseness4/5

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

Front-loaded with the artifact definition and the alternative-tool routing before the delivery mechanics, and each clause carries information. The final two sentences on host views and link forwarding are somewhat long and partially duplicate the delivery guidance given earlier, costing a little tightness.

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 document-producing tool with an output schema, the description covers everything an agent needs: what is produced, how it differs from an invoice and from a pure calculation, request accounting, layout default, and link idempotency. Return-value structure is correctly left to the output schema.

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 description coverage is 100%, so the nested request object and every field are already documented in the schema; the description adds little semantic detail there. Its only genuine addition is that delivery sits beside request rather than inside it and selects file vs. link by host — useful but already spelled out in the delivery property description, so this sits at baseline.

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 and artifact ("Erzeugt einen Berechnungsbogen als PDF") and immediately disambiguates the resource from an invoice ("die Herleitung einer Berechnung, keine Rechnung"). It also names the two sibling tools an agent might confuse it with, so the tool can be selected without opening any schema.

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 an explicit trigger ("Rufe es, wenn nur die Herleitung als Datei gebraucht wird") plus exclusions routed to named alternatives: rvg_create_invoice for a billable invoice, rvg_calculate when no file is needed. It further conditions the delivery argument on host capability (Claude Code/claude.ai vs. ChatGPT), which is decision guidance rather than restated schema.

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

All ONYST RVG 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.

Resources

Need Help?