Skip to main content
Glama

chrono24_autocomplete

Read-only

Chrono24's own search-box typeahead suggestions for a partial query: each suggested phrase with its own live result count and the Chrono24 search URL it resolves to. Useful for building a search box against chrono24_search without guessing a full query.

Input Schema

NameRequiredDescriptionDefault
QueryYesPartial search text, e.g. \

Output Schema

NameRequiredDescriptionDefault
dataYesThe tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / Query / description
      Added value: +"Partial search text, e.g. \\"
  2. First observed

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and live-source profile is covered. The description adds that counts are 'live' and that each suggestion carries a resolvable URL, but since an output schema exists this largely restates return structure rather than adding behavioral context like rate limits or freshness windows.

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?

Two tightly written sentences, front-loaded with what the tool returns before the routing hint. No redundant or filler clauses.

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?

A single-parameter, read-only tool with an output schema and annotations covering safety, so little is left to explain. The description is sufficient to call it correctly, though it could note whether suggestions are localized or how many are returned for completeness.

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?

Only one parameter, and schema description coverage is reported at 100%, so the schema carries the semantics. The description's 'partial query' phrasing adds nothing beyond 'Partial search text' in the schema; 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?

States a specific mechanism (Chrono24's search-box typeahead suggestions) for a specific input (partial query) with named outputs (suggested phrase, live result count, resolved search URL). It is clearly distinguishable from chrono24_search, which returns full results rather than suggestions.

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?

Explicitly names the sibling chrono24_search and the scenario that selects this tool ('building a search box ... without guessing a full query'), giving clear when-to-use context. It stops short of an explicit when-not-to-use or a comparison of the two tools' outputs.

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.