Skip to main content
Glama
Sign In

BGB (Germany)

by io.arxo
OverviewDiscussionsAdmin

law_case_ask

Read-only

Die Operation ask: eine registrierte Sache eines Fallpakets über ihren verankerten Abhängigkeiten ausführen und die Antwort zurückgeben: standardmäßig eine Projektion des Auswertungsdokuments ohne Beweisgraph, bei responseMode full oder proof: true das kanonische Dokument mit Beweis und Manifest. Die Frage ist JSON nach query.schema.json (query), eine evaluate-Zeichenkette (evaluate + queryId), eine gespeicherte queryId ohne query oder card + args. Eine Verweigerung der Vorbereitung ist ein Fehler mit LDC-*-Code, nie eine leere Antwort.

Input Schema

NameRequiredDescriptionDefault
argsNodie Kartenparameter: Name → Zeichenkettenausdruck der Sprache
cardNodie id einer Karte eines installierten Katalogs
caseNothe name of the case declaration from [[cases]]; optional when there is only one case
proofNotrue — das vollständige Dokument mit Beweisgraph (dasselbe wie responseMode full); false — die Projektion. Dieselbe Form wie bei law_ask.
queryNothe question as JSON per query.schema.json; queryId is a URN in the namespace of the package, or a short name given in queryId
packageYesthe path to the case package (the directory holding law.toml) from the root of the repository
queryIdNoohne query/evaluate — die Wahl einer gespeicherten queries/*.json nach Kurzname oder voller URN; mit evaluate — die id der ausgeführten Frage
evaluateNothe string `evaluate <expression>;`; requires queryId
responseModeNocompact — eine Projektion für einen Agenten: results, positions, conflicts, das Manifest, Issues oberhalb von info und alle Hashes bleiben erhalten, proofGraph ist durch Hash, Wurzeln und Knotenzahl ersetzt (Feld proof), die Zahl der entfernten info-Issues steht in issuesOmitted. full — das vollständige kanonische Auswertungsdokument, dasselbe, das `law ask` schreibt; proof: true verlangt dasselbe. Der resultHash der Projektion ist der des vollständigen Dokuments; für Beweis oder Veröffentlichung ist full nötig.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / card / description
      Previous value: -"die id einer Karte eines installierten Katalogs DECISION-0190"New value: +"die id einer Karte eines installierten Katalogs"
    • changedInput schema / properties / evaluate / description
      Previous value: -"the string `evaluate <expression>;` §267.2; requires queryId"New value: +"the string `evaluate <expression>;`; requires queryId"
    • addedInput schema / properties / proof
      Added value: +{
+  "description": "true — das vollständige Dokument mit Beweisgraph (dasselbe wie responseMode full); false — die Projektion. Dieselbe Form wie bei law_ask.",
+  "type": "boolean"
+}
    • addedInput schema / properties / responseMode
      Added value: +{
+  "description": "compact — eine Projektion für einen Agenten: results, positions, conflicts, das Manifest, Issues oberhalb von info und alle Hashes bleiben erhalten, proofGraph ist durch Hash, Wurzeln und Knotenzahl ersetzt (Feld proof), die Zahl der entfernten info-Issues steht in issuesOmitted. full — das vollständige kanonische Auswertungsdokument, dasselbe, das `law ask` schreibt; proof: true verlangt dasselbe. Der resultHash der Projektion ist der des vollständigen Dokuments; für Beweis oder Veröffentlichung ist full nötig.",
+  "enum": [
+    "full",
+    "compact"
+  ]
+}
  2. First observed

TDQS

B3.2/5.0
Behavior4/5

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

Annotations already declare readOnly/no-destructive/closed-world, and the description adds genuinely new behavior: the default response is a projection without proof graph, responseMode full or proof:true yields the canonical document with proof and manifest, and a failed preparation returns an error with an LDC-* code rather than an empty answer. That error-contract sentence is exactly the kind of context annotations cannot carry.

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?

One dense but well-ordered block: purpose first, then output shape, then accepted input forms, then failure semantics. No filler sentences, though the German sentences are long and jargon-loaded, and the language mismatch with the English tool/parameter names adds friction.

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?

With 9 parameters, nested objects, and no output schema, the description carries the return-value burden and does so by distinguishing the compact projection (results, positions, conflicts, manifest, hashes, proofGraph collapsed) from the full canonical document. Missing only a plain-language statement of what the answer content represents for a first-time caller.

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 100%, so the baseline is 3. The description does add the mutually-exclusive invocation combinations (query alone, evaluate+queryId, stored queryId alone, card+args), which the per-parameter schema does not state, but its responseMode and proof explanations largely duplicate the schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a verb ('ausführen') and resource ('eine registrierte Sache eines Fallpakets'), but 'Sache' and 'verankerte Abhängigkeiten' are internal jargon that does not tell an outside agent plainly that this answers a question against a case package. It never contrasts itself with the very similar sibling law_ask (which it only mentions in a parameter description), so discrimination relies on the agent reading schemas.

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

Usage Guidelines2/5

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

No statement of when to choose this tool over law_ask, law_query, or law_argue, and no exclusions or prerequisites. The input-form list (query / evaluate+queryId / stored queryId / card+args) hints at usage shapes but is parameter guidance, not tool-selection guidance.

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

All BGB (Germany) 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