Skip to main content
Glama

ikeytz – Schlüsseldienst Ludwigsburg

Get Discovery

get_discovery
Read-only

WHAT: Fetch one public discovery file from www and return a line window. REQUIRED which. IDs (aliases folded): llms, llms-full, llms-index, llms-keywords, llms-serp, llms-impressum-kontakt, llms-orte-geo, llms-urheberrecht, llms-copyright, llms-mcp-server, llms-mcp-web, robots, sitemap-txt, sitemap-xml, ai-txt, ai-plugin, answer-engine, ai-catalog, auth-md, mcp-readme, agent-skills. summary = the line window (this is the file body). Use offset/limit + nextOffset to page. Byte caps apply (keywords huge). Unknown which → unknown_discovery. Prefer dedicated get_llms_txt / get_sitemap_txt / get_llms_mcp_server when you know the file. Policy files say ai-train=no.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of lines to return after offset. Omit or null = return every remaining line in the fetch window (not the whole disk file if the fetch itself truncated). Clamped to 1..10000. For sitemap.txt (~807 URL lines) omit limit to get the full list. For llms-keywords.txt prefer a window; the file is huge.
whichYesRequired discovery id or alias. Examples: llms, llms-full, llms-mcp-server, llms-mcp-web, sitemap-txt, robots, ai-txt, ai-catalog, auth-md, mcp-readme, llms-orte-geo, llms-urheberrecht. Underscores accepted (llms_full → llms-full). get_ prefix and _txt suffix stripped.
offsetNo0-based line index into the fetched UTF-8 file (split on \n). 0 = first line. Omit = 0. Combined with limit = a sliding window. Use nextOffset from the previous result to page. Does not count bytes; one line can be a long URL.

Output Schema

TableJSON 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.
pathNoPublic path on www, e.g. /llms.txt or /.well-known/ai.txt
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.
limitNoApplied line limit, or null if the caller omitted limit.
whichNoResolved discovery id after alias fold (llms, sitemap-txt, ai-catalog, …).
localeNoLocale actually used for URLs (args.locale or de).
offsetNoApplied 0-based line offset.
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.
totalUrlsNohttp(s) lines in the fetched text.
truncatedNotrue if fetch hit a byte cap OR offset+limit left more lines.
nextOffsetNooffset + returnedLines when more lines remain; else null. Pass as the next offset.
totalLinesNoLine count of the fetched text (after byte cap).
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.
returnedUrlsNoLines in this window that start with http(s)://
bytesReturnedNoUTF-8 byte length of the returned body window.
returnedLinesNoHow many lines are in summary/body this call.

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses important behaviors: it returns a line window rather than a full file, byte caps apply, unknown IDs produce unknown_discovery, and policy files may contain ai-train=no. These details are genuinely useful and go well beyond what annotations alone convey.

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 compact and front-loaded: the WHAT statement comes first, followed by the required parameter and the critical ID list, then operational caveats. Although it is dense, the ID enumeration is necessary for a tool with no enum constraint, and every sentence contributes actionable information.

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 generic discovery fetcher with many possible inputs, the description covers the full range of valid IDs, the unknown-ID error, byte caps, paging via nextOffset, and when to route to dedicated sibling tools. Since an output schema exists, the return value shape does not need to be repeated here; nothing essential 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 per the rubric. The description earns the extra point by enumerating the full canonical ID/alias list (llms, llms-full, robots, sitemap-txt, etc.) and by explaining alias folding ('llms_full → llms-full'), which the schema only hints at with examples. The paging guidance further clarifies offset/limit semantics 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 opens with a specific verb-resource pair: 'Fetch one public discovery file from www and return a line window.' It clearly distinguishes get_discovery from the many dedicated get_* siblings by positioning it as the generic discovery-file fetcher and explicitly naming dedicated alternatives such as get_llms_txt and get_sitemap_txt.

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?

The description gives explicit routing guidance: 'Prefer dedicated get_llms_txt / get_sitemap_txt / get_llms_mcp_server when you know the file,' which tells the agent when NOT to use this tool. It also describes paging with offset/limit and nextOffset, and notes the unknown-which error case, so the conditions of use are clear.

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.

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