Dollea Cosmetics Salon

Freie Salontermine finden

salon_find_slots

Read-onlyIdempotent

Tatsächlich freie Termine für ausgewählte Salonleistungen finden. Mitarbeiterzuordnung, kombinierte Behandlungen und Buchungsfristen werden berücksichtigt. Eine Mitarbeiterpräferenz wird nicht stillschweigend ersetzt.

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": {
      "service_ids": "<service_ids>",
      "from_date": "<from_date>"
    },
    "name": "salon_find_slots"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	Maximale Anzahl zurückgegebener Ergebnisse innerhalb der veröffentlichten Grenze.
`offset`	No	Ergebnisposition für die nächste Seite; next_offset aus der vorherigen Antwort verwenden.
`to_date`	No	Letzter lokaler Kalendertag des begrenzten Suchzeitraums, einschließlich dieses Tages.
`language`	No	Gewünschte Sprache für Texte und Anzeigeformate: de, en oder ru.	de
`staff_id`	No	Optionaler ausdrücklich gewünschter Mitarbeiter. Eine ungeeignete oder nicht verfügbare Präferenz wird nicht ersetzt.
`from_date`	Yes	Erster lokaler Kalendertag in München, im Format JJJJ-MM-TT.
`service_ids`	Yes	Aktuelle numerische Leistungskennungen aus salon_search_services. Mehrere Leistungen werden als zusammenhängender Besuch geprüft.

Output Schema

Name	Required	Description	Default
`slots`	Yes
`total`	Yes
`business`	Yes
`language`	Yes
`timezone`	Yes
`local_date`	Yes
`next_offset`	Yes
`service_ids`	Yes
`contract_version`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 9, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds genuine context beyond that: it accounts for staff assignment, combined treatments and booking deadlines, and states that a staff preference is not silently substituted — a behaviorally meaningful guarantee about result fidelity.

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?

Three short sentences, front-loaded with the core purpose and only mildly redundant on the staff-preference point already covered in the schema. No 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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. For a 7-parameter read-only search with 100% schema coverage, the description supplies sufficient purpose and behavioral context; only explicit sibling routing is missing.

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 every parameter (limit, offset, to_date, language, staff_id, from_date, service_ids) is already documented in the schema. The description adds no parameter-level detail, and its staff-preference sentence duplicates the staff_id schema description, so the baseline of 3 applies.

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

Purpose4/5

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

The description states a specific verb+resource ('Tatsächlich freie Termine ... finden') scoped to selected salon services, which cleanly separates it from salon_search_services (service catalog) and the booking siblings. It does not name any sibling explicitly, so the differentiation is inferable rather than stated.

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?

Usage is implied: it is the availability-discovery step that feeds salon_prepare_booking/salon_confirm_booking, and it consumes service_ids produced by salon_search_services (noted only in the schema, not the description). There is no explicit when-to-use/when-not or alternative routing in the description text.

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

All Dollea Cosmetics Salon 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?