Skip to main content
Glama
sepehr071

snapp-mcp

by sepehr071
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Order costs

food_order_costs
Read-onlyIdempotent

Retrieves delivery fees, ETA, minimum order, and coupon conditions for a restaurant before you recommend it. Use to compare true order costs at a given delivery point.

Instructions

Get the extra costs and conditions of ordering from one restaurant.

Use before recommending a restaurant: delivery fee, ETA, minimum order and coupons (with the basket total each needs and whether it is first-order only). Packaging is per item in food_menu.

Input Schema

NameRequiredDescriptionDefault
latYesDelivery point latitude.
longYesDelivery point longitude.
vendor_codeYesVendor code, e.g. '947evd' (from food_search / food_restaurants).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv0.2.0
    • changedInput schema / properties / lat / description
      Previous value: -"Latitude of the delivery point (Iran: ~25 to ~40)."New value: +"Delivery point latitude."
    • removedInput schema / properties / lat / title
      Removed value: -"Lat"
    • changedInput schema / properties / long / description
      Previous value: -"Longitude of the delivery point (Iran: ~44 to ~63)."New value: +"Delivery point longitude."
    • removedInput schema / properties / long / title
      Removed value: -"Long"
    • changedInput schema / properties / vendor_code / description
      Previous value: -"Snappfood vendor code, e.g. '947evd' (from food_search / food_restaurants)."New value: +"Vendor code, e.g. '947evd' (from food_search / food_restaurants)."
    • removedInput schema / properties / vendor_code / title
      Removed value: -"Vendor Code"
    • removedInput schema / title
      Removed value: -"food_order_costsArguments"
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "title": "food_order_costsDictOutput",
-  "type": "object"
-}New value: +null
  2. First observedv0.1.1

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description earns credit for disclosing the payload shape: delivery fee, ETA, minimum order, coupon conditions with required basket total, first-order-only flag. It does not mention that results are location-dependent beyond the implied lat/long inputs, nor any rate/caching behavior.

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 tight sentences: the action first, then the usage trigger, then the enumerated return fields. The trailing pointer to food_menu for packaging is dense with routing value and costs nothing in length.

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

Completeness5/5

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

With no output schema, the description compensates by enumerating the meaningful return fields (fees, ETA, minimum, coupon conditions, basket thresholds). Combined with the read-only annotations and fully documented inputs, an agent has everything needed to call and interpret it.

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%, including where vendor_code comes from, so the schema already carries the parameter burden. The description adds only that lat/long select the restaurant's delivery point, which is a marginal over-specification of the obvious.

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?

Specific verb + resource: 'Get the extra costs and conditions of ordering from one restaurant', with the scope (one vendor, per delivery point) made explicit. It also carves out a boundary against food_menu by stating packaging costs live there instead.

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?

'Use before recommending a restaurant' gives a concrete decision point in the agent's workflow, which is unusually actionable. It does not state any exclusion or negative case (e.g. what to use when no coordinates are known), so it stops short of full when/when-not guidance.

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