harristeeter-mcp

Overview Schema Source Related Servers Discussions Admin

ht_oa_place_order

Destructive

Places a Harris Teeter Order Ahead pickup order for deli, subs, pizza, or platters, paid at the store, and requires explicit user confirmation before the request is sent.

Instructions

Place a Harris Teeter Order Ahead order (deli, subs, pizza, platters) for pickup — paid at the store when you collect it. The store starts preparing it and there is no cancel from here, so this sends real work to a person. NOT yet verified against a live order: the first real use is the test. Asks the user to confirm first: a confirmation prompt where the client supports one; otherwise the first call returns a preview and a confirmToken, and only a repeat call with that token proceeds (see MCP_CONFIRM_MODE).

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": {
      "date": "<date>",
      "time": "<time>",
      "items": "<items>"
    },
    "name": "ht_oa_place_order"
  }
}

Input Schema

Name	Required	Description
`date`	Yes	Pickup date, YYYY-MM-DD.
`time`	Yes	A pickup time from ht_oa_list_pickup_times, e.g. "5:30 PM".
`items`	Yes
`confirmToken`	No	ONLY for the two-step confirmation fallback (a client without MCP elicitation). The confirmToken from this same tool's phase-1 "confirmation-required" response, passed back ONLY after the user has seen that preview and explicitly approved it in chat — never on the first call, never invented, never reused. Call again with the same arguments. Ignored when the client supports elicitation.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Nov 13, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and openWorldHint=true, but the description goes further: it says the store begins real preparation, there is no cancel path, money is exchanged at pickup, and the flow is unverified against a live order. It also documents the two-phase confirmation/token handshake, which an agent cannot infer from annotations.

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?

The description is dense but front-loaded: purpose and payment terms first, then risk, then confirmation mechanics. Every sentence carries operational weight, though the confirmation paragraph is slightly convoluted and could be tightened.

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 destructive, real-world, unverified ordering tool with no output schema, it supplies everything an agent needs: side effects, irreversibility, payment location, test status, and the exact confirmation protocol including the fallback token path.

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 75%, and the description reinforces the confirmToken contract: first call returns a preview, repeat call with the token proceeds, token must never be invented or reused. It adds less on date/time/items, but those are documented in the schema.

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 description names a specific verb and resource — 'Place a Harris Teeter Order Ahead order' — and scopes it to deli, subs, pizza and platters for pickup. This clearly separates it from sibling cart/menu tools like ht_add_to_cart and ht_oa_list_menu without needing their schemas.

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?

It establishes the usage context: order for pickup, pay at the store, no cancellation available afterward. What is missing is an explicit statement of when to prefer this over alternatives (e.g. ht_add_to_cart for regular grocery orders), though the pickup-format framing implies it.

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