Skip to main content
Glama

find_pickup_points

Read-only

Vyhledá výdejní místa dopravce podle města, PSČ, ulice nebo názvu (Zásilkovna vč. Z-BOXů, Balíkovna, PPL ParcelShop, DPD Pickup). Vrácené id patří do create_order.pickupPointId.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNopočet výsledků (výchozí 10)
queryYesměsto, PSČ, ulice nebo název (min. 2 znaky), např. „Brno Lidická“ nebo „60200“
shippingIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description does not contradict them. It adds useful integration context by noting the returned id is meant for create_order, but it does not describe response shape, pagination, availability, or provider-specific caveats.

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 sentences, front-loaded with the core action and followed by the integration note. There is no filler, repetition, or unnecessary detail; every sentence earns its place.

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?

For a three-parameter lookup tool with annotations and no output schema, the description provides enough to call it correctly: carriers, search criteria, and the meaning of the returned id. A minor gap is that it does not mention what other fields appear in results, but the tool's evident purpose is to supply an id for order creation.

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?

The schema documents query and limit, but shippingId has no description. The description's carrier list ('Zásilkovna vč. Z-BOXů, Balíkovna, PPL ParcelShop, DPD Pickup') gives human-readable meaning to the otherwise opaque enum values, and it reinforces query semantics with city/PSČ/street/name examples.

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 and resource: 'Vyhledá výdejní místa dopravce' (searches carrier pickup points), lists the supported carriers, and states the search dimensions. It is clearly distinct from the order/catalog siblings and directly explains what the tool returns.

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?

The sentence 'Vrácené id patří do create_order.pickupPointId' clearly frames the tool as a prerequisite lookup step before order creation. It establishes the intended usage context, though it does not explicitly name alternative tools or when-not-to-use conditions.

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