Slowhop MCP

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

No annotations exist, and the description carries the full burden well: live JSON API fetch with latency expectations and an unblocker fallback, plus the null/true/false semantics of `stay.available` including the unverified-minimum-stay case. It also warns that `price`/`breakdown` are null when unavailable, that such stays must never be quoted, and that `calculator_quote` is reference-only because Slowhop's calculator ignores minimum stays and refused pets.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with the purpose before the detail, but the body is a very dense, very long block, and the inline enumeration of the entire result object consumes a large share of it. Without an output schema that enumeration is defensible, yet it is heavy enough to slow an agent down compared with a tighter field list.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description correctly documents the full return shape including the optional `stay` branch, the breakdown sub-fields, and the degraded `calculator_quote` path. For a 7-parameter tool with conditional pricing behavior, an agent has everything needed to call it and to interpret an empty or refused result.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description goes beyond it by explaining that date_from/date_to switch on Slowhop's own pricing calculator and that the result is computed for "the party" (adults, children ages, pets), which is behavioral meaning the schema does not convey. It does not restate individual parameter formats, but it doesn't need to.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource ("Full details of one slowhop.com place") and then enumerates the payload domains: units, house rules, pets policy, amenities, fees, discounts, cancellation, plus optional stay pricing. It is unambiguously distinguishable from slowhop_search, which it names as the source of the slug.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It routes the agent explicitly ("Get the slug from slowhop_search") and explains the condition that activates the pricing path ("With date_from/date_to it also prices the stay for the party"). What's missing is an explicit statement of when not to use it, e.g. browsing many places should go to slowhop_search rather than repeated calls here.

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

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

No annotations are provided, so the description carries the full burden and does so thoroughly: caching (5 min, `no_cache` bypass), fetch latency including unblocker fallback, currency and per-whole-party pricing rules, the `available: false` / `restriction` semantics, and the crucial note that an empty match with `count: 0` and a `note` is a successful result rather than an error. This is exactly the operational context that prevents misreading results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and mode-switching are front-loaded, but the body becomes a dense block of near-run-on prose covering output fields, price arithmetic, restriction types and empty-result behavior in long semicolon-chained sentences. Much of it is valuable, yet the output-field explanation overlaps the existing output schema and the 'slowhop_place with the same dates gives the exact...' point is restated twice.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 16-parameter search tool with no annotations, the description covers everything an agent needs: scope, date-dependent semantics, price units, availability flags, sorting, pagination via `page`/`total_count`, and the success-vs-error distinction for empty results. Nothing required to call it correctly is missing.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds genuine meaning beyond the schema: `place` resolution behavior (autocomplete, town radius via `radius_km`), that `price_min`/`price_max` are nightly prices for the whole party in PLN with foreign prices converted, and how party composition affects returned pricing. It does not add much on `filters` beyond the schema's own enumeration, keeping it short of a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource ('Search slowhop.com, the Polish marketplace of slow stays') and immediately enumerates the property types covered (cabins, agritourism, glamping, tiny houses). It explicitly routes downstream detail to the sibling: 'pass a listing's `slug` to slowhop_place for the description, units, house rules...', so the agent can separate search from detail without reading either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states the two modes of use and their consequences: WITH dates availability is checked and unbookable places are flagged, WITHOUT dates availability is not checked and prices are 'from' prices — plus the directive 'never quote an available: false place for the dates asked'. It names the alternative (slowhop_place) and the exact condition for switching to it (need for description, units, house rules, or exact quote).

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