Chop it: meal planning, recipes, pantry and shopping

Count and compare saved weeks

analyse_saved_weeks

Read-onlyIdempotent

Answers how many Saved Weeks the user has and how many repeat the same meals in one read-only data response, without opening the app or creating drafts. Compares every stored recipe ID, ignoring week titles and dinner order, and reports serving-setting differences and unknown portions separately. Empty weeks are counted separately. Counts are returned by default. includeGroups adds up to 50 duplicate week references; nextOffset continues those references and expectedRevision accepts the previous analysisRevision to detect changed data. Reads the complete account library on the server, without loading full recipes, images, nutrition or shopping data. Requires a linked Chop It account.

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": "analyse_saved_weeks"
  }
}

Input Schema

Name	Required	Description
`offset`	No	Offset over duplicate week references, using nextOffset from the previous page.
`includeGroups`	No	Include a page of duplicate week names and IDs; counts alone are returned by default.
`expectedRevision`	No	analysisRevision from the previous page; a changed analysis is refused so pagination can restart.

Output Schema

Name	Required	Description
`note`	Yes
`groups`	Yes
`offset`	Yes
`hasMore`	Yes
`complete`	Yes	All owner-scoped rows were enumerated and checked against exact counts. This is not a transactional snapshot.
`pageSize`	Yes
`emptyWeeks`	Yes
`nextOffset`	Yes
`totalWeeks`	Yes
`extraCopies`	Yes	Weeks beyond one per matching meal-selection group; not necessarily identical serving settings.
`returnedWeeks`	Yes
`groupsIncluded`	Yes
`analysisRevision`	Yes
`duplicateGroupCount`	Yes
`uniqueMealSelections`	Yes	Distinct non-empty recipe ID multisets, ignoring titles and dinner order.
`weeksInDuplicateGroups`	Yes
`groupsWithUnknownServings`	Yes
`groupsWithDifferentServingSettings`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds real context beyond that: it reads the complete account library server-side without loading full recipes, images, nutrition or shopping data, requires a linked Chop It account, ignores week titles and dinner order when comparing, and reports serving-setting differences and unknown portions separately.

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?

Front-loaded with the core answer, then scoped to comparison rules and pagination behaviour. Dense but every clause carries information; slightly heavy with the stacked clauses about what is not loaded.

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 3-param read-only analysis tool with an output schema present, the description covers scope, comparison semantics, empty-week handling, pagination continuity, auth requirement and data footprint. Nothing an agent needs 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, but the description adds meaning by tying includeGroups to 'up to 50 duplicate week references', tying offset ('nextOffset') to continuing those references, and tying expectedRevision to the previous analysisRevision for change detection. The only friction is that the offset parameter is described via a nextOffset term that appears in the response rather than 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?

States a specific verb+resource pair ('answers how many Saved Weeks... how many repeat the same meals') in one read-only response. It explicitly contrasts with app-opening and draft-creating flows, which separates it from siblings like get_saved_week, list_saved_weeks and create_weekly_menu.

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?

Makes the use case clear: count and compare duplicates without opening the app or creating drafts. It does not name an explicit alternative tool or a when-not condition, so the routing is implied rather than spelled out.

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

All Chop it: meal planning, recipes, pantry and shopping tools Inspect

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

Need Help?