Skip to main content
Glama
Pantrist-dev

Pantrist

Official
by Pantrist-dev
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Hybrid

Pantrist MCP Server

A Model Context Protocol server that wraps the Pantrist REST API, so an LLM client (Claude Desktop, the Claude web/mobile connector, Cursor, …) can manage shopping lists, the pantry, recipes and the week plan in natural language.

It's a thin wrapper — no business logic. Every tool maps to an existing REST endpoint and forwards the caller's Bearer token. The HTTP client is generated from the public OpenAPI spec (src/generated/pantrist-api.ts), so request/response types track the API automatically; only the curated tool layer (src/tools.ts) is hand-written.

Documentation

  • docs/ARCHITECTURE.md — components, the token context, request flow, transports, regeneration.

  • docs/AUTHENTICATION.md — OAuth flow, token-type ↔ tool compatibility, multi-user isolation, the consent-page dependency.

  • docs/DEPLOYMENT.md — full env var reference, remote/ingress setup, scaling, security checklist.

  • docs/TOOLS.md — every tool's args, REST mapping, and the item shape.

  • docs/LIMITATIONS.md — known rough edges (read before relying on it in production).

Related MCP server: Bring! Shopping MCP Server

Two transports

Transport

When

Auth

stdio (src/stdio.ts)

Local PoC, single user, Claude Desktop

Bearer from PANTRIST_TOKEN env

Streamable HTTP (src/http.ts)

Remote, multi-user, the Claude connector

Per-request Bearer, obtained by the client via OAuth

Connecting Claude to the hosted server

If you just want to use Pantrist with Claude (not self-host), the public endpoint is https://mcp.pantrist.app/mcp. Pick whichever Claude surface you're on; in every case the first tool call walks you through an OAuth login to your Pantrist account, no token to copy by hand.

Claude.ai (web or desktop app)

  1. claude.ai → profile menu → Settings → Connectors

  2. Click Add custom connector

  3. Fill in:

    • Name: Pantrist

    • URL: https://mcp.pantrist.app/mcp

  4. Save → click Connect. A popup opens the Pantrist consent page.

  5. Sign in → authorize → the popup closes.

  6. Start a new chat — the Pantrist tools (shopping list, pantry, week plan, recipes) show up in the tool selector. Try "What's on my shopping list?"

Claude Code (CLI)

claude mcp add pantrist --transport http https://mcp.pantrist.app/mcp

In the session, run /mcp to confirm it's listed. The first tool call triggers the OAuth flow in your browser.

Claude Desktop (manual config)

For Claude Desktop versions that support remote MCP, in ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or the equivalent on Windows/Linux:

{
  "mcpServers": {
    "pantrist": {
      "type": "url",
      "url": "https://mcp.pantrist.app/mcp"
    }
  }
}

Restart Claude Desktop. First tool use kicks off OAuth.

Sanity-checks if it doesn't work

# 200 OK + {"status":"ok"}
curl -fsS https://mcp.pantrist.app/healthz

# 401 + a WWW-Authenticate header pointing at /.well-known/oauth-protected-resource
curl -i -X POST https://mcp.pantrist.app/mcp -H 'Content-Type: application/json' -d '{}'

# JSON listing api.pantrist.app as the authorization server
curl -fsS https://mcp.pantrist.app/.well-known/oauth-protected-resource

If all three succeed but the connector flow still fails, the API's OAUTH_AUTHORIZE_URL probably isn't set to a browser-facing consent page — see the warning in the OAuth dependency note.

Quick start (stdio — fastest path)

You can validate the whole tool set in a couple of minutes without touching OAuth, using an API key you generate in the Pantrist web app.

git clone https://github.com/NLueg/pantrist-mcp.git
cd pantrist-mcp
npm install
npm run build

# Generate an API key at
# https://www.pantrist.com/documentation/api-docs — it never expires,
# which is what you want for a server that stays running.
export PANTRIST_BASE_URL=https://api.pantrist.app
export PANTRIST_TOKEN=<uuid>_<secret>
export PANTRIST_LIST_ID=<a-list-uuid>   # optional; or call list_lists

npm run dev:stdio   # or: node dist/stdio.js

Claude Desktop config

claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "pantrist": {
      "command": "node",
      "args": ["/ABSOLUTE/PATH/pantrist-mcp/dist/stdio.js"],
      "env": {
        "PANTRIST_BASE_URL": "https://api.pantrist.app",
        "PANTRIST_TOKEN": "<uuid>_<secret>",
        "PANTRIST_LIST_ID": "<list-uuid>"
      }
    }
  }
}

Restart Claude Desktop, then try: "What's on my shopping list?" or "Add milk and eggs."

Remote (Streamable HTTP + OAuth)

export PANTRIST_BASE_URL=https://api.pantrist.app
export MCP_PUBLIC_URL=https://mcp.pantrist.app   # public URL of THIS server
export MCP_ALLOWED_HOSTS=mcp.pantrist.app        # optional DNS-rebinding guard
export PORT=8787
npm run dev:http   # or: node dist/http.js

Then add it in Claude as a Custom Connector with URL https://mcp.pantrist.app/mcp. The server also exposes GET /healthz for probes. Full env reference, ingress, and scaling notes are in docs/DEPLOYMENT.md.

How the OAuth handshake flows

Claude ──POST /mcp (no token)──▶ MCP server
        ◀── 401 + WWW-Authenticate: resource_metadata=".../oauth-protected-resource"
Claude ──GET  /.well-known/oauth-protected-resource ──▶ MCP server
        ◀── { authorization_servers: ["https://api.pantrist.app"] }
Claude ──GET  /.well-known/oauth-authorization-server ─▶ pantrist-api   (RFC 8414)
Claude ──POST /access-token/register ─────────────────▶ pantrist-api   (RFC 7591 DCR)
Claude ──(browser) authorization_endpoint ────────────▶ consent page   (see below)
Claude ──POST /access-token/token (code + PKCE) ──────▶ pantrist-api   → access_token
Claude ──POST /mcp (Bearer access_token) ─────────────▶ MCP server ──▶ REST API

The MCP server is the Resource Server; the Authorization Server is the Pantrist API. The token Claude receives is the API Bearer, so this server just forwards it.

⚠️ Dependency — the consent page. The API's authorization_endpoint must be a browser-navigable login/consent page (the API's /access-token/authorize is a guarded JSON endpoint and can't be navigated to directly). Host one on the app (e.g. https://pantrist.app/oauth/authorize) and set the API's OAUTH_AUTHORIZE_URL env to point at it. Until that page exists, use the stdio path above with a manually-supplied token.

Tools

Tool

REST route

list_lists

GET /list

list_shopping_items

GET /list/{listId}/shoppingList

add_shopping_item

POST /list/{listId}/shoppingList/add-by-name

check_shopping_item

POST /list/{listId}/shoppingList/{itemId}/check

delete_shopping_item

DELETE /list/{listId}/shoppingList/{itemId}

list_pantry_items

GET /list/{listId}/pantryList

add_pantry_item

POST /list/{listId}/pantryList/add-by-name

reduce_pantry_amount

PUT /list/{listId}/pantryList/{itemId}/change-amount

update_pantry_item

GET + PUT /list/{listId}/pantryList/{itemId} (metadata-only; stock changes go through reduce_pantry_amount)

search_recipes

POST /recipe/filter

get_recipe

GET /recipe/{recipeId}

delete_recipe

DELETE /recipe/{recipeId}

get_week_plan

GET /list/{listId}/weekPlan?from=&to=

update_week_plan_day

PUT /list/{listId}/weekPlan/{date}

Most tools accept an optional listId; if omitted they use PANTRIST_LIST_ID in stdio mode only (HTTP mode requires it explicitly — see multi-user isolation). Full argument and item-shape details are in docs/TOOLS.md.

All of these are public API endpoints (present in /swagger-ui-json), so this wrapper needs only the published spec — never the private API source. That keeps the door open to open-sourcing this directory as its own repo.

Tests

npm test     # Node's built-in test runner (via tsx) — wiring + multi-user gating

Regenerating the API client

Two steps, run when the API contract changes:

# 1. In the pantrist-api repo: emit the public OpenAPI spec
#    (Nest preview mode — no DB). Writes the snapshot directly into
#    ../pantrist-mcp/openapi/pantrist-openapi.json.
cd ../pantrist-api && pnpm generate:openapi

# 2. Back here: regenerate the typed client from that spec.
cd ../pantrist-mcp && npm run generate:client

Both the spec snapshot (openapi/pantrist-openapi.json) and the generated client (src/generated/pantrist-api.ts) are committed so the project builds without network access. The tool layer in src/tools.ts is hand-authored and not regenerated.

Environment

See .env.example.

Available Tools

14 tools
add_pantry_itemA

Add a new item to the pantry by name. The API matches name against the user's article catalog: an existing article is reused (its category, unit, price history preserved); a new article is created on first use. Returns the resulting ArticleDto. Use reduce_pantry_amount to change stock on an item already in the pantry; use update_pantry_item to rename or change unit / category; use add_shopping_item to put it on the shopping list instead.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesItem name, e.g. "Milk". Matched case-insensitively against the article catalog; matches reuse the existing article.
amountNoInitial stock amount. Defaults to 1 if omitted (server-applied).
unitIdNoUnit id, e.g. "pieces", "g", "ml", "l". Defaults to "pieces" if omitted (server-applied). Discover supported ids by inspecting any existing pantry item's `unitId`.
listIdNoList UUID — call `list_lists` to discover one. Optional only in stdio mode (falls back to the PANTRIST_LIST_ID env var); required explicitly in HTTP mode.

TDQS

A4.5/5.0
Behavior4/5

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

Discloses that name matching reuses existing articles or creates new ones, and mentions the return type ArticleDto. Missing idempotency or auth details but adequate given complexity.

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 sentences, front-loaded with purpose, no redundancy. Could be slightly tighter but no waste.

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?

Covers essential behavior and return type despite no output schema. Does not explain error cases but sufficient for a create-tool.

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 covers all parameters (100%). Description adds useful defaults for amount and unitId, and how to discover unitId and listId, enhancing beyond 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 clearly states 'Add a new item to the pantry by name' and distinguishes from siblings like reduce_pantry_amount, update_pantry_item, and add_shopping_item.

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

Usage Guidelines5/5

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

Explicitly tells when to use this tool vs alternatives, e.g., 'Use reduce_pantry_amount to change stock; use update_pantry_item to rename; use add_shopping_item for shopping list.'

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

add_shopping_itemA

Add an item to the shopping list by name. The API matches name against the user's article catalog: an existing article is reused (its category, unit and price history preserved); a new article is created on first use. Returns the resulting ArticleDto. To add directly to the pantry instead use add_pantry_item; to mark an existing shopping item bought use check_shopping_item.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesItem name, e.g. "Milk". Matched case-insensitively against the article catalog; an exact match reuses the existing article.
listIdNoList UUID — call `list_lists` to discover one. Optional only in stdio mode (falls back to the PANTRIST_LIST_ID env var); required explicitly in HTTP mode.

TDQS

A4.6/5.0
Behavior4/5

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

No annotations provided, so description carries full burden. It explains article matching logic (reuse vs create), and returns ArticleDto. It also mentions listId as optional in stdio mode. Minor lack: doesn't specify which shopping list is used if listId omitted, but still adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with no redundancy. The first sentence states the core action, the second adds behavioral nuance, the third provides usage guidance with sibling references. Every sentence earns its place.

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?

Given no output schema, the description mentions the return type 'ArticleDto', which is sufficient. Input parameters fully covered. Alternative tools referenced. Only minor gap: no explanation of what the 'shopping list' is, but context implies the user's main list.

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%, but description adds value by explaining case-insensitive matching for name and the context-dependent optionality of listId. This goes beyond what the schema descriptions alone provide.

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 starts with a clear verb-resource pair: 'Add an item to the shopping list by name.' It distinguishes from siblings by naming specific alternatives like add_pantry_item and check_shopping_item.

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

Usage Guidelines5/5

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

The description explicitly states when to use this tool vs alternatives: 'To add directly to the pantry instead use add_pantry_item; to mark an existing shopping item bought use check_shopping_item.' It also clarifies listId optionality across modes.

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

check_shopping_itemA

Check off a shopping-list item. The list's settings decide the actual effect: markDone flags the item as bought (stays on the list, struck through), removeOnCheck deletes it, and moveOnCheck transfers it into the pantry. Mutates state and returns the updated row. To unconditionally remove regardless of list settings use delete_shopping_item; for stock changes on a pantry item use reduce_pantry_amount.

ParametersJSON Schema
NameRequiredDescriptionDefault
itemIdYesItem uuid (from `list_shopping_items[].uuid` or `add_shopping_item`).
listIdNoList UUID — call `list_lists` to discover one. Optional only in stdio mode (falls back to the PANTRIST_LIST_ID env var); required explicitly in HTTP mode.

TDQS

A4.6/5.0
Behavior4/5

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

No annotations provided, so description carries full burden. Discloses mutation, return type ('returns the updated row'), and three possible behaviors (markDone, removeOnCheck, moveOnCheck) based on list settings. Could mention idempotency or error cases, but overall sufficiently transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences: purpose, effects, mutation/return, alternatives. Front-loaded and efficient with no unnecessary words.

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?

Given complexity (3 behaviors, mutation, no output schema), description covers key aspects: behavior variants, alternatives, return type. Could mention error handling or prerequisites, but remains adequate for selection and invocation.

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 description coverage is 100%, baseline 3. Description adds meaning beyond schema by specifying where to get itemId ('from list_shopping_items[].uuid or add_shopping_item') and explaining listId optionality and fallback to env var. Adds useful context.

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?

Describes checking off a shopping-list item with specific verb and resource. Distinguishes from siblings delete_shopping_item and reduce_pantry_amount by explaining when to use each.

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

Usage Guidelines5/5

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

Explicitly states when to use this tool vs alternatives: 'To unconditionally remove regardless of list settings use delete_shopping_item; for stock changes on a pantry item use reduce_pantry_amount.' Also explains conditional behavior based on list settings.

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

delete_recipeA

Delete a recipe you own, unconditionally and irreversibly. The API rejects deletes for recipes belonging to another user with a 403; that error surfaces verbatim to the caller. Preview with get_recipe before calling to confirm authorship and contents.

ParametersJSON Schema
NameRequiredDescriptionDefault
recipeIdYesRecipe uuid. Hard-delete is permanent — confirm ownership via `get_recipe` first.

TDQS

A4.9/5.0
Behavior5/5

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

No annotations provided, but description fully covers behavioral traits: unconditional irreversible delete, error behavior (403 passed verbatim), and recommendation to confirm ownership. Transparent about all key aspects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences with no redundancy. First sentence states core action, second explains error handling, third gives actionable tip. No wasted words.

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?

No output schema exists, but description adequately covers behavior, error conditions, and precondition. Complete for a simple delete operation without needing return value details.

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?

Single parameter recipeId with 100% schema description coverage. Description reinforces schema info and adds context about hard-delete permanence, going beyond baseline 3.

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?

Clear verb 'Delete' with specific resource 'a recipe you own' and description of unconditional and irreversible action. Distinct from sibling tools like delete_shopping_item.

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

Usage Guidelines5/5

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

Explicit guidance to preview with get_recipe before deleting, along with note about 403 error for unauthorized attempts. Provides clear when-to-use and precaution.

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

delete_shopping_itemA

Remove an item from the shopping list, unconditionally and irreversibly (no soft-delete, not affected by list removeOnCheck setting). Returns a confirmation string; the row is gone after the call returns. Use check_shopping_item instead if you want list-setting-dependent behaviour (mark done / move to pantry) rather than a hard delete.

ParametersJSON Schema
NameRequiredDescriptionDefault
itemIdYesItem uuid (from `list_shopping_items[].uuid`). Hard-delete is permanent — verify before calling.
listIdNoList UUID — call `list_lists` to discover one. Optional only in stdio mode (falls back to the PANTRIST_LIST_ID env var); required explicitly in HTTP mode.

TDQS

A5/5.0
Behavior5/5

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

No annotations provided, but description fully discloses behavior: 'unconditionally and irreversibly', 'no soft-delete', 'not affected by list removeOnCheck setting', 'row is gone after call returns'. Returns a confirmation string.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, no wasted words. Highly efficient.

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?

No output schema, but describes return value as confirmation string. For a simple delete tool, all necessary context provided.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage 100%, but description adds critical context: itemId warning about permanence, listId source and optionality explanation.

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?

Description clearly states 'Remove an item from the shopping list' with specific verb and resource, and explicitly distinguishes from sibling tool check_shopping_item.

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

Usage Guidelines5/5

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

Explicitly tells when to use this tool (hard delete) and when to use alternative (check_shopping_item for list-setting-dependent behavior). Also notes unconditional and irreversible nature.

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

get_recipeA

Get a single recipe by its uuid. Read-only. Returns a full RecipeDto with name, description, ingredients[], steps[], imageUrls[], totalTime, categories[], etc. Use search_recipes to discover recipe uuids; use delete_recipe to remove one you own.

ParametersJSON Schema
NameRequiredDescriptionDefault
recipeIdYesRecipe uuid (from `search_recipes[].results[].uuid` or `list_pantry_items[].pantrySettings.linkedRecipeUuids`).

TDQS

A4.5/5.0
Behavior4/5

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

Declares 'Read-only' and lists the returned fields (RecipeDto with name, ingredients, etc.), filling the gap left by missing annotations. No other behaviors (rate limits, auth) are mentioned, but the core safety trait is covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, each sentence earns its place. No wasted words, clear and efficient structure.

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?

No output schema, but the description fully describes the return structure (fields of RecipeDto). Combined with clear input guidance and context from siblings, the description is complete for the tool's complexity.

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% and already explains the parameter's source. The description reinforces this but adds no new meaning beyond the schema, so 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?

The description clearly states 'Get a single recipe by its uuid' – a specific verb and resource. It distinguishes from siblings by referencing 'search_recipes' for discovery and 'delete_recipe' for removal.

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

Usage Guidelines5/5

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

Explicitly advises using 'search_recipes' to find uuids before calling this tool, and points to 'delete_recipe' for deletions. Provides clear when-to-use and when-not-to-use guidance.

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

get_week_planA

List meal-plan entries between two dates (inclusive). Read-only. Returns an array of day objects — [{ date, list: [{ type: "recipe" | "manual", uuid?, name? }, …] }, …] — one per day that has any entries. Days with no plan are omitted from the response (so an empty array means nothing is planned in the range, not that the range is invalid). To set or clear a single day use update_week_plan_day.

ParametersJSON Schema
NameRequiredDescriptionDefault
fromYesRange start (inclusive), YYYY-MM-DD. Must be ≤ `to`; same value as `to` returns one day.
toYesRange end (inclusive), YYYY-MM-DD.
listIdNoList UUID — call `list_lists` to discover one. Optional only in stdio mode (falls back to the PANTRIST_LIST_ID env var); required explicitly in HTTP mode.

TDQS

A4.4/5.0
Behavior4/5

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

No annotations exist, so the description fully covers behavioral traits. It discloses read-only nature, return format (array of day objects with date and list), omission of days without entries, and the meaning of an empty array. Could mention idempotency or error handling but is already very helpful.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded with the main purpose, then return format, then disambiguation. Every sentence adds value, and there is no redundant or misleading information.

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?

Without an output schema, the description adequately describes the return format and edge cases (empty array). It provides a complete picture for a read operation, though it could optionally mention error responses. Overall, it balances depth and brevity well.

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%, so the description does not need to add much about parameters. It briefly mentions the return format but does not elaborate on parameters beyond what the schema provides, which is acceptable given high schema coverage.

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 clearly states the tool lists meal-plan entries between two dates, is read-only, and distinguishes it from the sibling tool 'update_week_plan_day' by specifying that one is for reading and the other for setting/clearing a single day.

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

Usage Guidelines5/5

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

Explicitly tells when to use this tool (reading meal-plan entries for a date range) and when to use the alternative 'update_week_plan_day' for setting/clearing a single day. Also explains that an empty response means no entries, not an invalid range.

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

list_listsA

List the shopping lists / pantries the authenticated user can access. Read-only. Returns an array of list objects each with uuid, name, and the user's role on that list — use a returned uuid as the listId argument for every other tool here.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden. It declares the tool is read-only and describes the return structure, which is sufficient for a simple list retrieval tool. No negative behaviors or prerequisites are mentioned, but none are needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no wasted words. The first sentence establishes purpose, the second provides actionable details. Information is front-loaded and easy to parse.

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 zero parameters and no output schema, the description fully covers what the tool does, what it returns, and how to use the results. It is complete for the tool's complexity.

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?

The input schema has zero parameters, so schema coverage is effectively 100%. The description adds value by explaining the return object structure (uuid, name, role) and how to use the uuid subsequently. Baseline is 4 for zero-parameter tools.

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 clearly states the tool lists shopping lists/pantries for the authenticated user, specifies it's read-only, and details the return fields (uuid, name, role). This distinguishes it from sibling tools that operate on individual items or recipes.

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?

The description explicitly mentions using the returned uuid as listId for other tools, providing clear usage context. However, it does not explicitly state when not to use this tool or name alternatives, but the purpose is sufficiently clear from the sibling tool names.

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

list_pantry_itemsA

List all items currently stocked in the pantry for listId. Read-only. Returns an array of ArticleDto objects (uuid, name, amount = current stock, unitId, pantrySettings.earliestBestBefore for expiry tracking, minimumAmount, …); empty array if the pantry is empty. For shopping items use list_shopping_items; for stock changes on an existing item use reduce_pantry_amount; for metadata changes use update_pantry_item.

ParametersJSON Schema
NameRequiredDescriptionDefault
listIdNoList UUID — call `list_lists` to discover one. Optional only in stdio mode (falls back to the PANTRIST_LIST_ID env var); required explicitly in HTTP mode.

TDQS

A4.2/5.0
Behavior4/5

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

Declares read-only behavior and describes return value structure including empty array case. No annotations provided, so description carries behavioral disclosure effectively.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, each earning its place: first states purpose and read-only nature, second details return type and sibling alternatives. No wasted words.

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?

Covers purpose, return type, parameter usage, and alternatives. Minor omission of error cases or rate limits, but sufficient for a simple read-only list operation.

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% with thorough explanation of listId (how to discover, mode-dependent optionality). Tool description references listId but adds no new semantics beyond 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?

Clearly states it lists all items in a pantry for a given listId, with read-only semantics. Explicitly differentiates from siblings like list_shopping_items and update_pantry_item.

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?

Provides explicit guidance on when to use this tool vs alternatives for shopping items, stock changes, and metadata updates. Also explains mode-dependent behavior of listId parameter.

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

list_shopping_itemsA

List all items currently on the shopping list for listId. Read-only. Returns an array of ArticleDto objects (uuid, name, amount, unitId, categoryUuid, pantrySettings, …); empty array if the list is empty. For pantry items use list_pantry_items; to add a new shopping item use add_shopping_item.

ParametersJSON Schema
NameRequiredDescriptionDefault
listIdNoList UUID — call `list_lists` to discover one. Optional only in stdio mode (falls back to the PANTRIST_LIST_ID env var); required explicitly in HTTP mode.

TDQS

A4.6/5.0
Behavior4/5

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

No annotations are provided, so the description carries full burden. It declares read-only, describes the return type (array of ArticleDto objects) and the empty array edge case, and explains the listId parameter behavior in different modes (stdio vs HTTP). Missing details on auth or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences that are front-loaded: first sentence states purpose and read-only nature; second sentence provides sibling references and return type. Every sentence earns its place with no wasted words.

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 tool's simplicity (one parameter, no output schema), the description covers purpose, usage, parameter details, return type, edge case (empty array), and sibling tool references. It is complete for its context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a description for listId. The description adds significant context: how to discover the list ID via 'list_lists', and the fallback behavior in stdio mode (env var) vs HTTP mode (required). This goes beyond 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 uses a specific verb 'list' and resource 'shopping items' with a required 'listId'. It clearly distinguishes from siblings like 'list_pantry_items' and 'add_shopping_item'.

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?

The description explicitly provides alternatives: for pantry items use 'list_pantry_items'; to add items use 'add_shopping_item'. It also indicates read-only behavior, but does not explicitly state when not to use the tool.

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

reduce_pantry_amountA

Change the stock of an existing pantry item by a delta. Mutates state and returns the updated ArticleDto. If autoRestock is true and the new amount lands at or below the item's minimumAmount, the item is also added to the shopping list in the same call. Use add_pantry_item to create a new pantry entry; use update_pantry_item for metadata (name / unit / category) — this tool only touches stock.

ParametersJSON Schema
NameRequiredDescriptionDefault
itemIdYesItem uuid (from `list_pantry_items[].uuid`). Item must already exist in the pantry — this tool does not create.
amountChangeYesDelta added to the current `amount` — negative consumes stock, positive restocks. Despite the tool name, positive values work for restocking too.
autoRestockNoIf true and the resulting amount drops to or below the item's `minimumAmount` (with `manageMinimumAmount` enabled), the item is also added to the shopping list in the same call. Defaults to false so reads stay quiet.
listIdNoList UUID — call `list_lists` to discover one. Optional only in stdio mode (falls back to the PANTRIST_LIST_ID env var); required explicitly in HTTP mode.

TDQS

A4.7/5.0
Behavior4/5

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

No annotations provided, so description carries full burden. It discloses mutation, return of updated DTO, autoRestock side effect, and that positive values work for restocking. Lacks permission or reversibility details but covers key behavioral traits well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with purpose, then details and sibling differentiation. No wasted words, efficient and clear structure.

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?

No output schema but description states return type. Parameters fully explained, sibling context provided, side effects documented. Complete for a tool of this complexity.

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%, baseline 3. Description adds extra context: amountChange clarifies positive works for restocking, autoRestock explains condition and default, listId distinguishes stdio vs HTTP modes. Adds meaningful value beyond 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 clearly states it changes stock by a delta, distinguishes from 'add_pantry_item' (create) and 'update_pantry_item' (metadata), and specifies the exact resource and action.

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

Usage Guidelines5/5

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

Explicitly tells when to use alternatives (add_pantry_item for creation, update_pantry_item for metadata) and explains the autoRestock side effect, providing clear when-to-use and when-not-to-use guidance.

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

search_recipesA

Search the user's recipes (their own creations + public favourites) by free-text and optional category filters. Read-only and paginated — returns { results: RecipeDto[], totalCount, totalPages, currentPage }. To fetch a single recipe by uuid use get_recipe; to delete one you own use delete_recipe.

ParametersJSON Schema
NameRequiredDescriptionDefault
searchStringNoFree-text query matched against recipe name, description, and ingredient names. Case-insensitive. Omit to list all recipes (still paginated).
categoriesNoOptional category filter — multiple categories are OR-combined. Values must come from the recipe-categories enum (e.g. "Breakfast", "Vegetarian", "LowCarb").
currentPageNo1-based page index. Page size is fixed server-side. Defaults to 1.

TDQS

A4.7/5.0
Behavior4/5

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

The description declares the tool is read-only, paginated, and specifies the return shape. While no annotations are provided, it could be more explicit about page size limits or ordering, but it adequately covers core behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences pack all essential information without wasted words: purpose, return format, and sibling references.

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?

Given no output schema, the description compensates by specifying the return structure. It covers all parameters and pagination. Could mention error handling or default page size, but overall sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description adds significant detail: free-text matching behavior (case-insensitive, fields searched), category OR-combination, and currentPage defaults and fixed page size.

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 clearly states the tool searches user recipes by free-text and category filters, differentiating itself from sibling tools like get_recipe and delete_recipe.

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

Usage Guidelines5/5

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

It explicitly mentions when to use search_recipes versus alternatives (get_recipe for single lookup, delete_recipe for deletion), providing clear context for agent decision-making.

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

update_pantry_itemA

Update an existing pantry item's metadata (rename, change unit, category, brand, notes). Internally fetches the current ArticleDto and PUTs back a merged copy — only the fields you pass change; everything else (current stock, price history, image URLs, autoRestock config) round-trips unchanged. Two API calls per invocation. Returns the updated ArticleDto. Use reduce_pantry_amount for stock changes — this tool only touches metadata.

ParametersJSON Schema
NameRequiredDescriptionDefault
itemIdYesItem uuid (from `list_pantry_items[].uuid`). Item must already exist.
nameNoNew name. Omit to keep current.
brandNoNew brand. Omit to keep current; pass null to clear an existing brand.
categoryUuidNoNew category uuid. Discover existing ones by inspecting `list_pantry_items[].categoryUuid`.
unitIdNoNew unit id, e.g. "pieces", "g", "ml". Changes how `amount` is displayed but does NOT convert existing stock.
notesNoFreeform notes. Omit to keep current; pass null to clear an existing note.
listIdNoList UUID — call `list_lists` to discover one. Optional only in stdio mode (falls back to the PANTRIST_LIST_ID env var); required explicitly in HTTP mode.

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description fully carries the burden. It discloses that the tool internally fetches the current `ArticleDto`, performs a PUT merge, makes two API calls per invocation, and returns the updated `ArticleDto`. This covers side effects, idempotency, and round-trip behavior comprehensively.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two tightly focused sentences. The first sentence defines purpose and scope; the second provides behavioral context, alternative tool, and expected return. Every word serves a purpose, no redundancy.

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 metadata update tool with 7 parameters, the description covers all needed context: what it does, when to use, behavioral details, and return type. No output schema exists, but the description mentions the returned `ArticleDto`. No gaps for effective agent invocation.

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?

All 7 parameters have schema descriptions (100% coverage), so baseline is 3. The description adds unique value by explaining the merge behavior and noting that listId is optional only in stdio mode, which enriches understanding beyond 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 clearly states the verb 'update', resource 'pantry item', and scope 'metadata' (rename, change unit, category, brand, notes). It also explicitly distinguishes from the sibling tool `reduce_pantry_amount` for stock changes, making its purpose unambiguous.

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

Usage Guidelines5/5

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

The description provides explicit guidance: 'Use `reduce_pantry_amount` for stock changes — this tool only touches metadata.' It also explains that only passed fields change, others round-trip unchanged, telling the agent when to use this versus alternatives.

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

update_week_plan_dayA

Replace the meal-plan entries for one day, identified by date. list is a full replacement — the day's previous entries are discarded. Pass an empty array to clear the day entirely. Returns the new { date, list }. To read a date range use get_week_plan; to read a single recipe referenced in the plan use get_recipe.

ParametersJSON Schema
NameRequiredDescriptionDefault
dateYesDay to set, YYYY-MM-DD. This single day is fully replaced — adjacent days are not touched.
listYesEntries planned for the day. Each entry is either a recipe ref or a manual free-text meal. Empty array clears the day.
listIdNoList UUID — call `list_lists` to discover one. Optional only in stdio mode (falls back to the PANTRIST_LIST_ID env var); required explicitly in HTTP mode.

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description effectively discloses the destructive nature (full replacement, discarding previous entries), the return format { date, list }, and the clearing capability. It lacks details on authorization, error handling, or rate limits, but covers the main behavioral traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise at four sentences, each adding value: main action, list behavior, clearing, return format, and alternatives. No superfluous content, and it is well-structured with front-loaded purpose.

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?

Given no output schema and no annotations, the description adequately covers the operation, its effect, return value, and conditional parameters. It could mention error cases or validation, but for a tool of this complexity, it is fairly complete.

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%, and the description adds meaning beyond the schema by explaining that list is a full replacement, how to clear the day, and the conditional requirement for listId. This enhances the agent's understanding of parameter usage.

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 clearly states the verb 'Replace' and the resource 'meal-plan entries for one day', and it distinguishes itself from sibling tools like get_week_plan and get_recipe by explicitly mentioning when to use them instead.

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?

The description provides explicit guidance on the list parameter (full replacement, empty array to clear) and mentions alternative tools for reading. It also notes conditional behavior for listId (optional in stdio, required in HTTP). However, it does not explicitly state when not to use this tool.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 13 tool updatesv0.1.1
    • Changedadd_pantry_item4 fields changed
      • addedInput schema / properties / amount / description
        Added value: +"Initial stock amount. Defaults to 1 if omitted (server-applied)."
      • changedInput schema / properties / listId / description
        Previous value: -"List UUID. Defaults to PANTRIST_LIST_ID if omitted."New value: +"List UUID — call `list_lists` to discover one. Optional only in stdio mode (falls back to the PANTRIST_LIST_ID env var); required explicitly in HTTP mode."
      • addedInput schema / properties / name / description
        Added value: +"Item name, e.g. \"Milk\". Matched case-insensitively against the article catalog; matches reuse the existing article."
      • addedInput schema / properties / unitId / description
        Added value: +"Unit id, e.g. \"pieces\", \"g\", \"ml\", \"l\". Defaults to \"pieces\" if omitted (server-applied). Discover supported ids by inspecting any existing pantry item's `unitId`."
    • Changedadd_shopping_item2 fields changed
      • changedInput schema / properties / listId / description
        Previous value: -"List UUID. Defaults to PANTRIST_LIST_ID if omitted."New value: +"List UUID — call `list_lists` to discover one. Optional only in stdio mode (falls back to the PANTRIST_LIST_ID env var); required explicitly in HTTP mode."
      • changedInput schema / properties / name / description
        Previous value: -"Item name, e.g. \"Milk\"."New value: +"Item name, e.g. \"Milk\". Matched case-insensitively against the article catalog; an exact match reuses the existing article."
    • Changedcheck_shopping_item2 fields changed
      • changedInput schema / properties / itemId / description
        Previous value: -"Item uuid."New value: +"Item uuid (from `list_shopping_items[].uuid` or `add_shopping_item`)."
      • changedInput schema / properties / listId / description
        Previous value: -"List UUID. Defaults to PANTRIST_LIST_ID if omitted."New value: +"List UUID — call `list_lists` to discover one. Optional only in stdio mode (falls back to the PANTRIST_LIST_ID env var); required explicitly in HTTP mode."
    • Addeddelete_recipe
    • Changeddelete_shopping_item2 fields changed
      • changedInput schema / properties / itemId / description
        Previous value: -"Item uuid."New value: +"Item uuid (from `list_shopping_items[].uuid`). Hard-delete is permanent — verify before calling."
      • changedInput schema / properties / listId / description
        Previous value: -"List UUID. Defaults to PANTRIST_LIST_ID if omitted."New value: +"List UUID — call `list_lists` to discover one. Optional only in stdio mode (falls back to the PANTRIST_LIST_ID env var); required explicitly in HTTP mode."
    • Changedget_recipe1 field changed
      • addedInput schema / properties / recipeId / description
        Added value: +"Recipe uuid (from `search_recipes[].results[].uuid` or `list_pantry_items[].pantrySettings.linkedRecipeUuids`)."
    • Changedget_week_plan3 fields changed
      • changedInput schema / properties / from / description
        Previous value: -"Start date, YYYY-MM-DD."New value: +"Range start (inclusive), YYYY-MM-DD. Must be ≤ `to`; same value as `to` returns one day."
      • changedInput schema / properties / listId / description
        Previous value: -"List UUID. Defaults to PANTRIST_LIST_ID if omitted."New value: +"List UUID — call `list_lists` to discover one. Optional only in stdio mode (falls back to the PANTRIST_LIST_ID env var); required explicitly in HTTP mode."
      • changedInput schema / properties / to / description
        Previous value: -"End date, YYYY-MM-DD."New value: +"Range end (inclusive), YYYY-MM-DD."
    • Changedlist_pantry_items1 field changed
      • changedInput schema / properties / listId / description
        Previous value: -"List UUID. Defaults to PANTRIST_LIST_ID if omitted."New value: +"List UUID — call `list_lists` to discover one. Optional only in stdio mode (falls back to the PANTRIST_LIST_ID env var); required explicitly in HTTP mode."
    • Changedlist_shopping_items1 field changed
      • changedInput schema / properties / listId / description
        Previous value: -"List UUID. Defaults to PANTRIST_LIST_ID if omitted."New value: +"List UUID — call `list_lists` to discover one. Optional only in stdio mode (falls back to the PANTRIST_LIST_ID env var); required explicitly in HTTP mode."
    • Changedreduce_pantry_amount4 fields changed
      • changedInput schema / properties / amountChange / description
        Previous value: -"Delta applied to the current amount; negative consumes."New value: +"Delta added to the current `amount` — negative consumes stock, positive restocks. Despite the tool name, positive values work for restocking too."
      • changedInput schema / properties / autoRestock / description
        Previous value: -"If true and the item lands at/below its minimumAmount, also re-add it to the shopping list. Defaults to false."New value: +"If true and the resulting amount drops to or below the item's `minimumAmount` (with `manageMinimumAmount` enabled), the item is also added to the shopping list in the same call. Defaults to false so reads stay quiet."
      • changedInput schema / properties / itemId / description
        Previous value: -"Item uuid."New value: +"Item uuid (from `list_pantry_items[].uuid`). Item must already exist in the pantry — this tool does not create."
      • changedInput schema / properties / listId / description
        Previous value: -"List UUID. Defaults to PANTRIST_LIST_ID if omitted."New value: +"List UUID — call `list_lists` to discover one. Optional only in stdio mode (falls back to the PANTRIST_LIST_ID env var); required explicitly in HTTP mode."
    • Changedsearch_recipes3 fields changed
      • addedInput schema / properties / categories / description
        Added value: +"Optional category filter — multiple categories are OR-combined. Values must come from the recipe-categories enum (e.g. \"Breakfast\", \"Vegetarian\", \"LowCarb\")."
      • addedInput schema / properties / currentPage / description
        Added value: +"1-based page index. Page size is fixed server-side. Defaults to 1."
      • addedInput schema / properties / searchString / description
        Added value: +"Free-text query matched against recipe name, description, and ingredient names. Case-insensitive. Omit to list all recipes (still paginated)."
    • Addedupdate_pantry_item
    • Changedupdate_week_plan_day4 fields changed
      • changedInput schema / properties / date / description
        Previous value: -"Day to set, YYYY-MM-DD."New value: +"Day to set, YYYY-MM-DD. This single day is fully replaced — adjacent days are not touched."
      • changedInput schema / properties / list / description
        Previous value: -"Entries planned for the day. Empty array clears the day."New value: +"Entries planned for the day. Each entry is either a recipe ref or a manual free-text meal. Empty array clears the day."
      • changedInput schema / properties / list / items / anyOf
        Previous value: -[
-  {
-    "additionalProperties": false,
-    "properties": {
-      "type": {
-        "const": "recipe",
-        "type": "string"
-      },
-      "uuid": {
-        "description": "Recipe uuid.",
-        "type": "string"
-      }
-    },
-    "required": [
-      "type",
-      "uuid"
-    ],
-    "type": "object"
-  },
-  {
-    "additionalProperties": false,
-    "properties": {
-      "name": {
-        "description": "Free text meal name.",
-        "type": "string"
-      },
-      "type": {
-        "const": "manual",
-        "type": "string"
-      }
-    },
-    "required": [
-      "type",
-      "name"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "additionalProperties": false,
+    "properties": {
+      "type": {
+        "const": "recipe",
+        "description": "Reference to a saved recipe by uuid.",
+        "type": "string"
+      },
+      "uuid": {
+        "description": "Recipe uuid (from `search_recipes` or `get_recipe`).",
+        "type": "string"
+      }
+    },
+    "required": [
+      "type",
+      "uuid"
+    ],
+    "type": "object"
+  },
+  {
+    "additionalProperties": false,
+    "properties": {
+      "name": {
+        "description": "Free-text meal name displayed in the plan.",
+        "type": "string"
+      },
+      "type": {
+        "const": "manual",
+        "description": "Free-text meal not tied to a stored recipe (e.g. \"leftovers\", \"takeout\").",
+        "type": "string"
+      }
+    },
+    "required": [
+      "type",
+      "name"
+    ],
+    "type": "object"
+  }
+]
      • changedInput schema / properties / listId / description
        Previous value: -"List UUID. Defaults to PANTRIST_LIST_ID if omitted."New value: +"List UUID — call `list_lists` to discover one. Optional only in stdio mode (falls back to the PANTRIST_LIST_ID env var); required explicitly in HTTP mode."
  2. 12 tool updatesv0.1.0
    • First observedadd_pantry_item
    • First observedadd_shopping_item
    • First observedcheck_shopping_item
    • First observeddelete_shopping_item
    • First observedget_recipe
    • First observedget_week_plan
    • First observedlist_lists
    • First observedlist_pantry_items
    • First observedlist_shopping_items
    • First observedreduce_pantry_amount
    • First observedsearch_recipes
    • First observedupdate_week_plan_day
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.5/5.0
Disambiguation5/5

Each tool targets a distinct action and resource (pantry, shopping, recipes, week plan, lists). Overlaps like check_shopping_item vs delete_shopping_item are clearly differentiated by behavior. No ambiguity between tools.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., add_pantry_item, check_shopping_item, update_week_plan_day). Verbs and targets are uniformly structured.

Tool Count5/5

14 tools cover the main domains (pantry, shopping, recipes, week plan, lists) with a balanced number per domain. No tool feels redundant or missing for the apparent scope.

Completeness4/5

Core workflows are covered, but gaps exist: no delete pantry item, no create recipe, and only reduce stock (no increase). Week plan and shopping list are well covered. Minor gaps, not severely incomplete.

Maintenance

ActivityActive
ResponsivenessUnresponsive

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • AnyList MCP Server

    davidashman
    F
    license
    A
    quality
    D
    maintenance
    Enables AI assistants to interact with AnyList for managing shopping lists, recipes, and meal planning. Users can retrieve recipe details, add ingredients to lists, and schedule meals on their AnyList calendar.
    10
    -

  • scraps-kitchen-mcp

    mitchmolstad
    A
    license
    Not graded
    quality
    C
    maintenance
    Household-aware kitchen brain for AI agents: manage pantry inventory with freshness tracking, shopping lists, recipe collections with cook notes and per-diner ratings, dietary profiles with allergen safety, and kitchen equipment — all through 27 tools with OAuth 2.1 authentication. Includes a free tool for ingredient-based recipe generation without an account (accounts are free!).
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Pantrist-dev/pantrist-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server