Skip to main content
Glama
Sign In

LastList

by com.lastlistapp
OverviewDiscussionsAdmin

Build a shopping plan

build_plan

Build a shopping plan for one of the user's lists: find stores near them, work out which stores actually carry which items, and recommend a single-stop or split trip. Use for 'where should I shop for this', 'plan my trip', 'can I get all of this at one store'. This is about routing a trip, not ranking prices — describe the result as where to go and what each stop covers.

Items must be REFINED first (the shopper picking which milk, what size). Items added through these tools are not, so a list you built here needs the user to open it in LastList once, which lands on the Suggestions page and walks them through it. This tool will tell you when that is needed, and refine_items is how you resolve it in conversation.

Location: if the user has planned this list in the app before, their saved location is reused and you don't need to ask. Otherwise pass a zip (or lat/lng); without one the tool will tell you to ask the user where they're shopping.

A big list can take a few minutes. If the plan isn't ready when this returns, you get a jobId — tell the user it's building and call get_plan to check.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "build_plan"
  }
}

Input Schema

NameRequiredDescriptionDefault
latNoLatitude, if the user gave coordinates.
lngNoLongitude, if the user gave coordinates.
zipNoZIP code to shop near. Overrides the list's saved location.
listIdNoList to plan. Defaults to the user's active shopping list.
radiusMilesNoHow far the user is willing to travel. Defaults to their saved radius.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only mark this as a non-read-only, open-world, non-destructive operation; the description goes well beyond that by disclosing the refinement prerequisite and its in-app remediation, location fallback behavior, and the async jobId/get_plan flow including expected latency ('a big list can take a few minutes'). This is exactly the behavioral context annotations cannot express.

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?

Purpose and trigger conditions are front-loaded in the first two sentences, followed by preconditions, location handling, and async behavior in a sensible order. It is on the long side and the LastList Suggestions-page detail could be compressed, but no paragraph is filler.

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 and an async, side-effecting operation, the description covers everything an agent needs: prerequisites, remediation tool, location inputs, timing expectations, and how to retrieve results. Nothing required to call it 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?

Schema coverage is 100%, so the baseline is 3; the description adds real value on top by explaining the conditional logic between saved location, zip, and lat/lng ('otherwise pass a zip... without one the tool will tell you to ask the user'). It doesn't elaborate on radiusMiles or listId defaults beyond what the schema already documents.

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?

The opening sentence gives a specific verb and resource plus the three sub-tasks it performs (find stores, match items to stores, recommend single-stop or split trip). It explicitly distinguishes itself from nearby-store lookup and price ranking, so an agent can place it against siblings like find_nearby_stores and show_alternatives.

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?

It supplies literal trigger phrases ('where should I shop for this', 'plan my trip', 'can I get all of this at one store') and an explicit exclusion ('routing a trip, not ranking prices'). It also names refine_items as the resolution path when items aren't refined, and get_plan as the follow-up when a job is returned.

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

All LastList toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources