Skip to main content
Glama

Flow Fuel Plans: optimize a truck fuel plan

optimize_fuel_plan

Flow Fuel Plans. Build an optimized diesel fuel plan for a truck route. Send the truck profile, current fuel, origin, and destination; ValveRide Flow routes the leg, discovers truck stops along it, prices them from its live retail diesel grid, applies your discount schedule on net price, and returns where to stop, how many gallons to buy, and the estimated savings (IFTA tax-aware). The response includes a tripId; to replan mid-trip, call again with that tripId, currentLocation set to the truck's live position, and the updated currentFuelGallons. A replan of the same trip costs far less than a new plan: on a monthly Flow Fuel Plans tier every 10 replans count as 1 plan, and from the trial credit a new plan draws $2.25 and a replan of the same trip $0.08. Monthly tiers: Starter $99/month for 200 plans, Growth $349/month for 1,000 plans, Partner $799/month for 3,000 plans. VENDOR RULE: if the user restricts fueling to a brand or network ("Love's only", "we can only fuel at Pilot or Flying J"), you MUST set vendorRule.allowedVendors to those brands. It is a hard rule: only those stations are considered and, if none works, the tool returns no_feasible_plan_under_vendor_rule instead of an off-brand stop. Put any discount the user mentions for that brand in discountSchedule with the same vendor in the SAME call (for example "10 cents off at Love's" = vendorRule.allowedVendors ["Loves"] plus discountSchedule [{vendor:"Loves", discountType:"CENTS_PER_GALLON", discountAmount:10}]). The response echoes vendorRule and appliedDiscounts so you can confirm both were enforced.

Input Schema

NameRequiredDescriptionDefault
truckYes
originYesWhere the trip starts, as {lat,lng} or a place string like "Des Moines, IA"
tripIdNoOptional: the tripId returned by this trip's first call. Pass it (with an updated currentLocation) to replan the SAME trip at the replan rate (10 replans count as 1 plan on a monthly tier); omit it for a new trip. Must match the trip's destination and be within 14 days.
optionsNoOptional planning knobs
taxRatesNoOptional per-jurisdiction diesel tax overrides; defaults to current US/CA rates
vendorRuleNoSTRICT vendor allowlist. Set this whenever the user says they can only fuel at certain brands ("Love's only"). Only stations of these brands are considered; the plan never falls back to other brands. Aliases are accepted (Love's / Loves / Love, Pilot / Flying J / PFJ, TA / Petro). Infeasible under the rule returns the structured error no_feasible_plan_under_vendor_rule.
destinationYesDestination as {lat,lng} or a place string like "Denver, CO"
currentLocationNoOptional: the truck's live position for a mid-trip replan. Defaults to origin; when set, the plan covers the remaining leg from here.
discountScheduleNoYour negotiated fuel discounts, applied on top of retail to optimize on net price
currentFuelGallonsYesFuel currently in the tank, in gallons

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / tripId / description
      Previous value: -"Optional: the tripId returned by this trip's first call. Pass it (with an updated currentLocation) to replan the SAME trip at the $0.08 replan rate; omit it for a new trip ($2.25). Must match the trip's destination and be within 14 days."New value: +"Optional: the tripId returned by this trip's first call. Pass it (with an updated currentLocation) to replan the SAME trip at the replan rate (10 replans count as 1 plan on a monthly tier); omit it for a new trip. Must match the trip's destination and be within 14 days."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing that calls are metered ($2.25 new plan, $0.08 replan from trial credit; 10 replans = 1 plan on monthly tiers) and that the tool fails with the structured error no_feasible_plan_under_vendor_rule rather than returning an off-brand stop. It also names the echoed response fields (tripId, vendorRule, appliedDiscounts) so the agent knows what to verify. Nothing contradicts readOnlyHint=false (a paid, server-side trip is created) or idempotentHint=false (each call re-plans).

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 purpose and return values, then the replan mechanics, then the vendor rule — a sensible ordering with no wasted opening. The one non-earning passage is the tier price list ('Starter $99/month for 200 plans, Growth $349/month...'), which is marketing detail an agent cannot act on mid-call.

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?

For a 10-parameter, nested-object tool with no output schema, the description still covers the return payload, error paths, cost model, and the two coupled-parameter traps (vendorRule + discountSchedule, tripId + currentLocation). Nothing an agent needs to call this correctly is missing.

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?

With 90% schema coverage the baseline is 3, and the description adds real cross-parameter semantics: the vendorRule.allowedVendors requirement and the instruction to mirror the same brand string into discountSchedule.vendor in the same call, with a worked example ('10 cents off at Love's'). It also explains tripId's lifecycle beyond the schema's own note. It does not touch most options knobs, but the schema already documents those.

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 and resource ('Build an optimized diesel fuel plan for a truck route') and then enumerates the pipeline it runs: routing, truck-stop discovery, live pricing, discount application, and what comes back (stops, gallons, savings, tripId). An agent can distinguish this from the sibling fuel_market_snapshot (market data) without opening either schema.

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

Usage Guidelines5/5

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

Gives explicit when-to-use branches: omit tripId for a new trip, pass tripId + currentLocation + updated currentFuelGallons to replan the same trip, and the 14-day/destination-match constraint. It also states a hard mandate ('VENDOR RULE ... you MUST set vendorRule.allowedVendors') with the exact paired discountSchedule call shape, and quantifies the cost incentive favoring replans over new plans.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources