ikeytz – Schlüsseldienst Ludwigsburg

Get Ort Datetime

get_ort_datetime

Read-only

WHAT: Europe/Berlin wall clock to the second + whenKey for prices. THIS www tool does NOT look up a place (no slug/plz). maps.ikeytz.com has a different geo clock tool. RULE: whenKey=day only Mo–Fr 08:00:00–17:59:59 Berlin and not a Baden-Württemberg statutory holiday; otherwise night (Sa, So, holiday, or 18:00–07:59). RETURNS ok, stand ('YYYY-MM-DD HH:MM:SS CEST|CET'), iso, unix, date, time, tz, timezone=Europe/Berlin, weekday, weekdayIso (1=Mon), whenKey, holiday (bool), holidayName (or null), rule, invoiceTool=get_invoice_line_items, pricesTool=get_prices. USE before invoicing. NEXT: get_invoice_line_items({situationKey, whenKey: 'now'}) or pass whenKey day|night.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`at`	No	Optional clock. Formats: ISO-8601 with Z or ±HH:MM; or YYYY-MM-DD; or YYYY-MM-DDTHH:MM[:SS] interpreted as Europe/Berlin if no offset; or unix seconds/ms number-as-string. Omit = now. Invalid → ok=false error=bad_datetime.
`locale`	No	HTML locale for canonicalUrl and path prefixes. de = default, URLs have no prefix (https://www.ikeytz.com/preise). en\|fr\|ru\|fa\|ar\|tr = prefix /{locale}/ (https://www.ikeytz.com/en/preise). Omit or empty = de. Does not change prices, phone numbers, or legal German names. Not a maps.ikeytz.com locale (maps is German-only).	de

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes	true = use summary, canonicalUrl, and extra keys. false = do not invent data; read error + hint and retry with valid args or open hint.
`tz`	No	Abbreviation.
`iso`	No	ISO-8601 with Berlin offset.
`date`	No	YYYY-MM-DD in Berlin.
`hint`	No	Present when ok=false. Absolute URL the agent should open or pass to get_ai_page / get_discovery.
`rule`	No	Human rule string for day vs night.
`time`	No	HH:MM:SS in Berlin (24h).
`tool`	Yes	Echo of the tool name that produced this object (e.g. get_service_area).
`unix`	No	Unix timestamp seconds.
`error`	No	Present when ok=false. Codes include: unknown_tool, unknown_place, unknown_auswahl, unknown_ratgeber, unknown_doc, unknown_discovery, faq_not_found, wissen_not_found, serp_not_found, q_required, bad_datetime, bad_when_key, plus HTTP errors from fetch.
`stand`	No	Human clock 'YYYY-MM-DD HH:MM:SS CEST\|CET' Europe/Berlin.
`locale`	No	Locale actually used for URLs (args.locale or de).
`holiday`	No	true if date is a BW statutory holiday.
`related`	No	Always includes https://www.ikeytz.com/llms.txt. Geo tools also include https://maps.ikeytz.com/llms.txt.
`summary`	No	Primary text for the model. For discovery tools this is the file window (possibly thousands of characters). For list tools a compact one-liner. Quote with attribution.
`weekday`	No	en-GB short weekday (Mon…Sun).
`whenKey`	No	Price bucket. Pass to get_invoice_line_items.whenKey or use whenKey=now there.
`timezone`	No
`pricesTool`	No
`weekdayIso`	No	ISO weekday 1=Monday … 7=Sunday.
`attribution`	Yes	Required citation: 'Quelle: Schlüsseldienst Ludwigsburg ikeytz (ikeytz.com) · ai-train=no · https://www.ikeytz.com/.well-known/ai.txt'
`holidayName`	No	German holiday name or null. Holidays force whenKey=night.
`invoiceTool`	No
`canonicalUrl`	No	Best URL to show the user: https://www.ikeytz.com… page, or tel:+49…, mailto:…, https://wa.me/…. Prefer this over constructing URLs.

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only declare readOnly, but the description discloses the exact day/night rule, holiday dependence, Baden-Württemberg holiday nuance, Berlin timezone, and the returned fields. This makes the tool's behavior predictable beyond what readOnlyHint conveys.

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?

The description is dense but cleanly structured with WHAT/THIS/RULE/RETURNS/USE/NEXT prefixes, and each fragment carries decision-relevant information. The core purpose is front-loaded, and the rule is stated precisely before workflow guidance.

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 read-only clock/time tool with two optional params and an output schema, the description fully covers the operational rule, timezone, holiday edge case, disambiguation from a sibling, and downstream pricing/invoicing usage. An agent has everything needed to call and apply the result correctly.

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 coverrage is 100%, so the two optional parameters are already fully documented. The description adds contextual framing (clock, prices, before invoicing) but no new syntax or parameter-level detail, so baseline 3 is appropriate.

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 opens with WHAT, stating it is a Europe/Berlin wall clock to the second plus a day/night price key, and explicitly disambiguishes it from a maps.ikeytz.com geo-clock and from place lookup. An agent can identify the tool's exact role without opening the 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?

It gives an explicit USE-before-invoicing instruction and a NEXT step calling get_invoice_line_items, and it says the maps tool is a different clock. It also states what the tool does NOT do (no slug/plz lookup), which prevents misuse for geo queries.

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

All ikeytz – Schlüsseldienst Ludwigsburg tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation3/5

Many tools have clearly distinct roles, but there is real overlap: get_discovery duplicates get_llms_txt/get_llms_mcp_server/get_sitemap_txt, get_it and get_mcp_hub describe the same machines, and get_page_summary is a stub that competes with get_ai_page/get_serp_snippet. The detailed descriptions help, but an agent could still misselect among the discovery and pointer tools.

Naming Consistency4/5

The overwhelming majority follow a consistent snake_case verb-noun pattern: get_*, list_*, compose_*, resolve_*. Minor deviations like site_overview, get_it, and find_by_keyword are readable but break the dominant convention.

Tool Count2/5

45 tools for a single small-business website is excessive and well above the 25+ threshold. Many tools are pointer/list aliases or discovery-file accessors that could be consolidated without losing capability.

Completeness4/5

Core workflows are well covered: identity, contact, emergency info, pricing, invoicing, service areas, FAQs, legal pages, and generic page content via get_ai_page. Minor gaps exist around explicit opening-hours details, existing customer reviews, and maps-domain functionality, but these are mostly declared out of scope rather than dead ends.

Resources

Need Help?