Skip to main content
Glama

delhaize_fetch_new_receipts

Fetch and save new Delhaize receipt images into receipts_inbox for OCR processing. Skips receipts already recorded, avoiding overwrites or deletions.

Instructions

Save the images of any NEW Delhaize receipts (this month and the previous months_back months) into receipts_inbox, ready for the existing pipeline.

Not read only: it writes image files into receipts_inbox. It is non destructive: it never overwrites, never deletes, and never edits receipts_all.json. A receipt already present in receipts_all.json is skipped.

After it runs, the images can be read (by the assistant or any OCR) and recorded in receipts_all.json by your own process; checking that the lines sum to the printed total before recording is strongly recommended.

Returns {new_count, saved:[{date, store, total, path}], missed:[...], next_step}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
months_backNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it declares 'Not read only: it writes image files', enumerates the non-destructive guarantees (never overwrites, never deletes, never edits receipts_all.json), and notes that already-recorded receipts are skipped. This is unusually rich behavioral disclosure, with only auth/permission notes absent.

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 purpose and scope are front-loaded in the first sentence, followed by behavioral guarantees and return shape. It is slightly verbose in the downstream-recording guidance, but each sentence carries actionable content.

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?

Despite a sparse schema (one optional param, no description), no annotations, and no output schema, the description supplies the write semantics, skip logic, and even the return keys {new_count, saved, missed, next_step}. An agent has enough to invoke it correctly, though auth requirements are unaddressed.

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 0% and the parameter has no description, but the description compensates by explaining months_back as 'the previous months_back months' relative to the current month, giving the agent the semantic meaning the schema lacks.

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 (save images), a precise resource (NEW Delhaize receipts), a scope (this month plus the previous months_back months), and a destination (receipts_inbox). The 'NEW ... receipts_all.json is skipped' qualifier clearly separates it from siblings like delhaize_list_receipts and delhaize_backfill_images.

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?

Context is implied: it fetches only new receipts and prepares them for the existing pipeline, and it advises reading images and recording them afterward. However, it never explicitly says when to prefer this over delhaize_backfill_images or delhaize_list_receipts, so the agent must infer the routing.

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