Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

pizzahut_delivery_estimate

Check Pizza Hut delivery serviceability for a store and address, then estimate delivery fees and pickup/dropoff time before checkout.

Instructions

Check Pizza Hut delivery serviceability and estimated fee for one store and address. Checks whether a Pizza Hut restaurant's delivery integration can deliver to a given address and, when it can, the estimated delivery fee (broken down by fee line item) and pickup/dropoff time. This is a checkout-time estimate -- it does not add an item to a cart or place an order, and takes no payment or account information. serviceable is true only when the upstream returned a real estimate; a false value with reason populated covers every other case seen live, such as the requested delivery_provider not being enabled at that store. For the default INTERNAL provider, a serviceable result does not by itself confirm the address is within a real deliverable radius -- see this endpoint's markdown doc for the caveat. order_subtotal materially affects the fee estimate, so it is required rather than defaulted. pickup_at defaults to 30 minutes from now (an "order now" style estimate) when omitted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cityYesDelivery address city
stateYesDelivery address state, two-letter code
address1YesDelivery address line 1
address2NoDelivery address line 2
latitudeYesDelivery address latitude
longitudeYesDelivery address longitude
pickup_atNoRFC3339 pickup time (default 30 minutes from now)
postal_codeYesDelivery address postal code
country_codeNoDelivery address country code (default US)
store_numberYesPizza Hut's store number, from /pizzahut/stores
order_subtotalYesOrder subtotal before fees, in dollars
delivery_providerNoDelivery provider to check (default INTERNAL)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.17.5
    • addedInput schema / properties / delivery_provider / enum
      Added value: +[
+  "DOORDASH",
+  "MOCK_DOORDASH",
+  "INTERNAL"
+]
  2. Addedv1.16.2

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the burden well: it explains that serviceable=true means a real upstream estimate, that false + reason covers all other observed cases (e.g. provider not enabled at the store), and that it takes no payment/account info. The one material gap is that the INTERNAL-provider radius caveat is deferred to a markdown doc rather than stated, so a behaviorally important caveat is flagged but not disclosed.

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?

Front-loaded with the core purpose and then layered with increasingly specific caveats, so an agent can stop reading early. It is efficient for the amount of behavior it must convey without annotations, though the caveat sentence is slightly verbose in pointing elsewhere rather than explaining.

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 12-parameter, no-annotation, no-output-schema tool this covers return-shape semantics (serviceable flag, reason, fee line items, pickup/dropoff time), the non-mutating contract, and the key parameter constraints. Only the deferred INTERNAL-radius caveat and minor per-parameter notes keep it from being fully complete.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it justifies why order_subtotal is required ('materially affects the fee estimate, so it is required rather than defaulted') and reiterates pickup_at's 30-minute 'order now' default semantics. The remaining 10 parameters get nothing beyond the schema, so it is not a 5.

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 verb+resource ('Check Pizza Hut delivery serviceability and estimated fee for one store and address') and immediately scopes it as a checkout-time estimate that does not touch cart, order, payment, or account. An agent can distinguish it from ordering/cart siblings (pizzahut_menu, pizzahut_bundle_choices) without opening another schema.

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?

Clearly frames when to use it (checkout-time serviceability/fee estimate before ordering) and what it is not for, which is the crucial routing distinction in this family. It does not explicitly name an alternative tool (e.g. a store lookup or a different brand's delivery estimate), so it stops short of full alternative routing.

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

Deploy Server

Other Tools