Skip to main content
Glama

Get food quality overview

get_food_quality_overview
Read-onlyIdempotent

Read an evidence-aware quality overview for 1 to 90 days, including history coverage and bounded meal assessments.

Instructions

Read an evidence-aware quality overview for one to 90 days, including history coverage and bounded meal assessments.

Input Schema

NameRequiredDescriptionDefault
daysNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only a hint about output content ('history coverage', 'meal assessments'), which is mild extra context rather than substantive behavioral disclosure such as what happens with sparse data.

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?

One sentence, front-loaded with the verb and resource, with zero filler or repetition. It is appropriately sized for a single-parameter read tool, though the jargon could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With rich annotations covering safety but no output schema, the description should explain what the overview returns; it gestures at 'history coverage and bounded meal assessments' without defining them. Adequate for calling the tool, incomplete for interpreting results.

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 0%, but the single parameter's bounds (1-90) are already encoded in the schema's minimum/maximum, and the description merely restates that range ('one to 90 days'). No default, format, or interpretation guidance is added beyond the schema, so it neither compensates nor misleads.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The verb 'Read' and resource 'quality overview' are present, but qualifiers like 'evidence-aware' and 'bounded meal assessments' are jargon that don't pin down what the overview actually contains. It also does nothing to distinguish itself from neighbors like get_product_quality or get_nutrition_summary.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no prerequisites, and no named alternative among the ~70 siblings (e.g. get_product_quality, get_nutrition_summary) that would tell an agent which quality/summary tool to pick. Usage must be inferred entirely from the name.

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

Deploy Server

Other Tools