Skip to main content
Glama

What is in the pantry

get_pantry
Read-onlyIdempotent

List what the user has told you is in their kitchen: pantry, fridge and freezer, with quantities when they gave one. For "what do I have", before suggesting a shopping list, or to check an ingredient before recommending a recipe. find_by_ingredients with no ingredients searches from this list directly.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
itemsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedOutput schema / additionalProperties
      Removed value: -false
    • removedOutput schema / properties / items / items / additionalProperties
      Removed value: -false
  2. Added

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description still adds meaningful context the annotations cannot: the data reflects only what the user has told the assistant, and quantities are optional, so the agent knows gaps are possible rather than treating the list as authoritative.

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 short sentences with zero filler, and the core definition is front-loaded before the usage triggers and the sibling relationship. Every clause carries information an agent needs.

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?

Output schema exists, annotations are rich, and no parameters need explaining, so the description only has to supply purpose, triggers and sibling routing — all present. Nothing required to call this 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?

Zero-parameter tool, so there is no parameter semantics to document and the baseline of 4 applies. Nothing in the description misdescribes the (empty) input.

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 and resource ('List what the user has told you is in their kitchen: pantry, fridge and freezer') and pins down the scope detail that quantities only appear when provided. It is immediately distinguishable from add_to_pantry and remove_from_pantry, which mutate the same resource.

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?

Gives three explicit trigger conditions — answering 'what do I have', before suggesting a shopping list, and before recommending a recipe — plus an explicit alternative route: find_by_ingredients with no ingredients searches from this list. That is when-to-use and alternative-selection guidance in a single sentence.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.