ah-mcp

Albert Heijn: Frequently Ordered Items

ah_get_frequent_items

Read-only

Find frequently ordered products from order history by counting item appearances and returning those ordered at least a minimum number of times, with names, IDs, counts, and last order dates.

Instructions

Get frequently ordered products by analysing order history. Fetches all fulfillments, expands each order's items, counts per product, and returns products ordered at least min_order_count times. Returns product_name, product_id, order_count, last_ordered_date. When you mention a product or recipe from the result, link its name to its url.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`min_order_count`	No	Minimum number of orders a product must appear in (default 3)

Output Schema

TableJSON Schema

Name	Required	Description	Default
`products`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.3.1Oct 5, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "products": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "last_ordered_date": {
+            "type": "string"
+          },
+          "order_count": {
+            "type": "number"
+          },
+          "product_id": {
+            "type": "number"
+          },
+          "product_name": {
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "product_name",
+          "product_id",
+          "order_count",
+          "url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "products"
+  ],
+  "type": "object"
+}

First observedv1.0.0Oct 5, 2026

TDQS

A4/5.0

Behavior4/5

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

With readOnlyHint=true already declaring safety, the description adds substantial value by disclosing the internal algorithm (fetching fulfillments, expanding items, counting) and the exact output fields (product_name, product_id, order_count, last_ordered_date). It also includes a specific post-processing instruction about linking product names to URLs, which is behavioral context not present in 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 a single, dense sentence that front-loads the core purpose and then details the mechanism and output. It is efficient with no wasted words, though the post-processing instruction could be separated for better clarity.

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?

Given the presence of an output schema, the description need not explain return values, but it does specify the exact fields returned. It also covers the computation method and provides a linking guideline, making it complete for an agent to understand the tool's behavior and usage.

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 coverage is 100% and the single parameter (min_order_count) is fully documented in the schema with its default value. The description mentions the threshold behavior but does not add syntax or format details beyond what the schema provides, fitting the baseline of 3 when the schema does the heavy lifting.

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 uses a specific verb ('Get frequently ordered products') and explains the underlying mechanism (analysing order history, expanding fulfillments, counting per product). It clearly distinguishes this from siblings like ah_get_orders or ah_get_products by focusing on aggregated frequency.

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?

The description implies usage through the min_order_count threshold explanation, which clarifies the filtering behavior. However, it does not explicitly state when to prefer this tool over alternatives like ah_get_favorite_lists or ah_search_products, leaving the agent to infer the context.

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