Skip to main content
Glama

DYOE Destination Intel ($0.05)

dyoe_destination
Read-only

Provides trip-planning agents pre-booking data: weather and 3-day forecast, local currency FX from USD, and a booking-site scam check in one call.

Instructions

Get what a trip-planning agent needs before it books, in one call: weather and 3-day forecast, local currency with live FX from USD, and a scam check on the booking site before it pays. Input: ?city=Athens&date=2026-11-20&currency=EUR&booking=hotel-site.com&budget=1500 Price: $0.05 USDC on Base per call, paid via x402.

Input Schema

NameRequiredDescriptionDefault
cityYesDestination city (e.g. Lisbon)
dateNoTravel date, YYYY-MM-DD (e.g. 2026-09-15)
budgetNoTrip budget in USD (e.g. 1500)
bookingNoBooking site domain to safety-check (e.g. booking.com)
currencyNoLocal currency code (e.g. EUR)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.1

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint; the description adds key behavioral context: it costs $0.05 USDC on Base and is paid via x402. It also frames the booking check as a pre-payment safety step, though it doesn't describe errors, rate limits, or return behavior.

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?

The description is compact and front-loads the purpose before giving an invocation example and price. The inline query-string example is useful but somewhat redundant with the schema, and the price is repeated from the title.

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

Completeness3/5

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

For a composite tool with no output schema, the description names the data categories returned but does not explain the response structure or how budget and date affect results. It covers payment and purpose, but leaves output expectations underspecified.

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?

Schema description coverage is 100%, so all five parameters are already documented in the schema. The example query string shows how the parameters compose, but it does not add meaning beyond the schema, such as how budget influences results.

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

Purpose4/5

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

States a specific composite purpose: weather/forecast, local currency with FX, and booking-site scam check in one call. The enumerated outputs make it clear what the tool does, though it does not explicitly name sibling alternatives like dyoe_weather or dyoe_fx.

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?

Provides clear timing guidance: use before the agent books or pays, and the 'one call' phrasing implies bundling those checks. It does not state when not to use it or compare it directly against sibling tools.

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