Skip to main content
Glama

ikeytz - Schlüsseldienst Ludwigsburg

Get Serp Snippet

get_serp_snippet
Read-only

WHAT: SERP title/description/URL slice for one marketing URL. Reads /llms-serp-{locale}.txt first (locale from URL prefix or args.locale), then falls back to full /llms-serp.txt. path or url required in practice. If path is not http(s), it is turned into www(locale, path). No match → serp_not_found. RETURNS matchContext (~200 chars before + 400 after) + source. Not a Google API.

Input Schema

NameRequiredDescriptionDefault
urlNoIf this starts with http, it is used as the search needle instead of path.
pathNoSite path (/preise) or used with locale to build the www URL to find in llms-serp.txt.
localeNoHTML 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

NameRequiredDescriptionDefault
okYestrue = use summary, canonicalUrl, and extra keys. false = do not invent data; read error + hint and retry with valid args or open hint.
hintNoPresent when ok=false. Absolute URL the agent should open or pass to get_ai_page / get_discovery.
toolYesEcho of the tool name that produced this object (e.g. get_service_area).
errorNoPresent 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.
localeNoLocale actually used for URLs (args.locale or de).
relatedNoAlways includes https://www.ikeytz.com/llms.txt. Geo tools also include https://maps.ikeytz.com/llms.txt.
summaryNoPrimary 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.
attributionYesRequired citation: 'Quelle: Schlüsseldienst Ludwigsburg ikeytz (ikeytz.com) · ai-train=no · https://www.ikeytz.com/.well-known/ai.txt'
canonicalUrlNoBest URL to show the user: https://www.ikeytz.com… page, or tel:+49…, mailto:…, https://wa.me/…. Prefer this over constructing URLs.
matchContextNoSurrounding SERP lines

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

With only readOnlyHint=true in annotations, the description carries real weight: it discloses the file-read order and fallback, the path-to-www(locale, path) normalization, the serp_not_found error case, and the return shape (matchContext ~200 before + 400 after, plus source). That is substantial behavioral context beyond the annotation.

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-loads the WHAT, then layers resolution logic, error case, and return shape in dense but ordered fragments. Slightly telegraphic with slash notation, but no sentence is wasted.

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?

An output schema exists, yet the description still gives the caller the essential fallback and error semantics, and it documents the practical requirement of path/url despite zero formally required params. Nothing critical to correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/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, but the description adds genuine meaning: it clarifies that a non-http path is converted to a www(locale, path) URL and that url takes precedence as the search needle when it starts with http. Locale derivation from URL prefix is also explained, exceeding the schema text.

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 resource ('SERP title/description/URL slice for one marketing URL') and clarifies it reads the llms-serp files rather than a live Google API. This clearly distinguishes it from the raw-file sibling get_llms_serp_txt.

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?

Explains the resolution order (locale file first, then full file), the 'path or url required in practice' constraint, and the no-match behavior. It does not explicitly name an alternative tool for a different need, so it stops short of full routing guidance.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources