Skip to main content
Glama
Sign In
harristeeter-mcp

harristeeter-mcp

by chrischall
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

ht_search_products

Read-only

Search Harris Teeter groceries by keyword to get UPC, brand, size, price, sale price and pickup availability at your store. Use the returned UPC to add items to your cart.

Instructions

Search Harris Teeter groceries by keyword at your pickup store — returns UPC, name, brand, size, price, sale price, unit price and pickup stock. Use the UPC with ht_add_to_cart. With Kroger API credentials set it runs without the browser (source: api.kroger.com); that API prices produce per pound where the website prices it per item.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "ht_search_products"
  }
}

Input Schema

NameRequiredDescriptionDefault
zipNoPrice at the Harris Teeter nearest this ZIP, for this call only (needs Kroger API credentials).
viewNoResponse shape: "compact" (default) drops fields the response already carries elsewhere; "full" returns every field this server understands; "raw" returns the upstream payload unprojected. compact returns a projection of the documented fields; "full" returns the API payload minified; "raw" pretty-prints it.
limitNoHow many results (default 10).
queryYesWhat to search for, e.g. "2% milk" or "bananas".
offsetNoSkip this many results, for paging.
locationIdNoPrice at this 8-digit store location id, for this call only (needs Kroger API credentials).
pickupOnlyNoOnly items available for pickup at your store (default true).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description goes further by disclosing the dual execution path (browser vs api.kroger.com with credentials) and a real data caveat that API prices are per pound where the website is per item — exactly the kind of trap an agent would otherwise fall into.

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?

Three dense sentences, front-loaded with purpose and return shape, then workflow, then the pricing caveat. No filler, though the pricing-mode sentence is slightly compressed and reads awkwardly on first pass.

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?

With no output schema, the description compensates by enumerating the returned fields, and it flags the optional credential requirement and the unit-pricing discrepancy. Pagination and the view modes are left entirely to the schema, which is acceptable given full schema coverage.

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%, so all seven parameters are already documented in the schema, including the view enum and zip/locationId credential note. The description adds only the implicit default of searching against the pickup store, so the baseline 3 is appropriate.

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 ('Search Harris Teeter groceries by keyword'), the scope ('at your pickup store'), and enumerates the returned fields (UPC, name, brand, size, price, sale price, unit price, pickup stock). An agent can immediately distinguish this browsing/search tool from cart, coupon, and recipe siblings.

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

Usage Guidelines3/5

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

Gives a downstream handoff ('Use the UPC with ht_add_to_cart') and context about the credential-based API path, which is genuinely useful. However, it never states when to prefer this over ht_get_products, ht_list_specials, or ht_get_weekly_ad, so alternative selection is left to inference.

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