Meistron

Aufträge suchen

auftraege_suchen

Read-onlyIdempotent

Listet Aufträge eines Zeitraums — etwa einer Woche — mit Titel, Termin, Status, Ort und Kunde. Ohne Zeitraum werden die nächsten anstehenden Termine gezeigt. Mit suche findet es einen Auftrag über Teil der Auftragsnummer oder des Titels — dann auch vergangene —, mit kunde_id die Aufträge eines Kunden. Die Kennung eines Treffers ist die Eingabe für auftrag_ansehen und rechnung_anlegen.

Input Schema

TableJSON Schema

Name	Required	Description
`bis`	No	Spätester Termin, JJJJ-MM-TT.
`von`	No	Frühester Termin, JJJJ-MM-TT.
`suche`	No	Teil der Auftragsnummer oder des Titels, z. B. „0118" oder „Heizung". Ohne Zeitraum werden dann auch vergangene Aufträge gefunden, nicht nur anstehende.
`anzahl`	No	Höchstens so viele (Vorgabe 25, Grenze 100).
`status`	No	Nur Aufträge in diesem Status.
`kunde_id`	No	Nur Aufträge dieses Kunden — die Kennung aus `kunden_suchen`.
`nur_unterminiert`	No	Nur Aufträge ohne Termin — die, die noch eingeplant werden müssen.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 20, 2026

addedInput schema / properties / kunde_id

Added value: +{
+  "description": "Nur Aufträge dieses Kunden — die Kennung aus `kunden_suchen`.",
+  "type": "string"
+}

addedInput schema / properties / suche

Added value: +{
+  "description": "Teil der Auftragsnummer oder des Titels, z. B. „0118\" oder „Heizung\". Ohne Zeitraum werden dann auch vergangene Aufträge gefunden, nicht nur anstehende.",
+  "maxLength": 60,
+  "type": "string"
+}

First observedAug 9, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds useful behavior beyond that: default time-range behavior, suche including past records, customer scoping, and the returned fields. It does not mention pagination or ordering, but those are minor given the strong annotation coverage.

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

Conciseness5/5

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

Three concise sentences put the primary purpose first, then refine behavior by input mode, then connect results to downstream tools. Every sentence earns its place and there is no redundant filler.

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?

For a read-only search/list tool, the description is largely complete: it states returned fields, default behavior, search modes, and how identifiers are used downstream. The lack of an output schema is compensated by listing result fields, though sorting and result-limit behavior are left to the 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 baseline is 3. The description adds some context for behavior with and without a time range, but it mostly restates what the schema already says about suche and kunde_id. It does not substantially enrich parameter understanding beyond the schema.

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 the operation: listing Aufträge over a period with specific result fields (Titel, Termin, Status, Ort, Kunde). It also differentiates this list/search tool from single-record siblings by noting that a result's Kennung is the input for auftrag_ansehen and rechnung_anlegen.

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

Usage Guidelines4/5

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

It gives clear usage context: no time range yields upcoming appointments, suche searches partial numbers/titles including past records, and kunde_id filters by customer. It does not explicitly state exclusions against sibling tools, but the downstream tool connection makes selection guidance clear enough.

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

All Meistron 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?