Planning method

Choose the smallest tool that answers the question

Asmaliana exposes six read-only tools with deliberately different jobs. Start with the narrowest operation that matches the user’s question, then follow the returned next_actions or inspect the evidence before making another call. A successful HTTP response means that a computation completed; it does not mean that a visit, booking, or live condition was confirmed.

Discover before guessing

Use /api/v1/meta, the generated OpenAPI document, or MCP tools/list when the integration does not already know the current contract. Discovery reports the active data mode, dataset version, limits, costs, and disabled capabilities. If the user has already supplied enough structured facts for a local calculation, do not make a discovery call just to repeat information already in the request.

Match intent to one tool

• Use search_melaka_places for a name, category, or bounded filter when you need candidate stable place IDs.
• Use get_melaka_place_facts when a stable place ID is known and the task needs field values, evidence, limitations, or source links.
• Use check_melaka_visit_window for one proposed arrival, date, stay duration, and required service.
• Use get_melaka_weather_advisory for the supported Melaka Tengah area forecast and provider state; it is not a venue sensor or a safety guarantee.
• Use plan_melaka_day to generate a deterministic candidate day from structured time, party, budget, preferences, and covered candidates.
• Use validate_melaka_itinerary when an itinerary already exists and needs a complete check of stops, windows, costs, transport assumptions, unknowns, and conflicts.

The two planner tools are not interchangeable: plan_melaka_day searches a bounded candidate set, while validate_melaka_itinerary evaluates the stops already supplied. A visit-window check is narrower than either planner and is useful when no multi-stop plan is needed.

A bounded sequence, not a retry loop

For an underspecified place question, a useful sequence is search_melaka_places → get_melaka_place_facts → (if a date is proposed) check_melaka_visit_window. For a structured day, use plan_melaka_day and then validate_melaka_itinerary if the draft changes or must be audited. Weather can be requested independently for the supported area and date.

Do not blindly retry a needs_verification result. Read blocking_unknowns, conflicts, assumptions, unchecked_dimensions, sources, and next_actions first. A next action is a suggested read-only follow-up, not permission to invent missing evidence or perform a write.

Read the envelope and status

Every tool response carries a request ID, schema/data version, data mode, sources, cache metadata, warnings, and next actions. Inside result, inspect the operation-specific assessment and evidence state. feasible means the declared hard constraints passed inside the published scope; it is not a live-operating or navigation promise.

Malformed input uses a client error, semantic conflicts remain explicit, quota responses include Retry-After and rate-limit headers, and unavailable required providers use a retryable service-unavailable response. Public tools are read-only: there is no booking, payment, inquiry, email, or inventory action to call.

Example decision rule

If the question is “which covered places match this category?”, call search. If it is “what evidence supports this one place?”, call facts. If it is “can I arrive at this time?”, call the visit-window check. If it is “draft a day from these constraints”, call the planner. If the stops are already chosen, validate them instead. When the required evidence is absent, preserve needs_verification and explain what would have to be checked next.