Skip to main content
Glama

dietaai_foods

Read-onlyIdempotent

Consulta o log de alimentos do usuário com os macros. Use date para um único dia (YYYY-MM-DD) OU start_date/end_date para um intervalo (máx 31 dias). Retorna os itens por refeição e os totais do dia (kcal, proteína, carbo, gordura, fibra, sódio, água).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNo
end_dateNo
start_dateNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool's safety profile is disclosed. The description adds behavioral context beyond annotations by specifying the return structure (items per meal and daily totals with macro breakdown), which helps the agent anticipate the response format without any contradiction.

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 a single, well-structured paragraph that front-loads the purpose, follows with usage rules, and ends with the return format. Every clause adds value, with no filler or repetition. It is concise yet comprehensive.

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 low complexity (3 optional params, no nested objects, no output schema), the description covers all necessary aspects: what it does, how to invoke it correctly (single day vs. range with max limit), and what the response contains. Combined with the informative annotations, this is fully complete for an agent to use effectively.

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 0%, so the description fully compensates by explaining the semantic purpose of each parameter: 'date' is for a single day, while 'start_date'/'end_date' define a range, and the max 31 days constraint adds meaning that the schema's plain string types lack. This is essential for correct invocation and goes well 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 starts with 'Consulta o log de alimentos do usuário com os macros', clearly stating the action (query) and the resource (user's food log with macros). It distinguishes this from sibling tools by focusing on food log and macro details, and the later phrase 'Retorna os itens por refeição e os totais do dia' clarifies the output scope. This is specific and 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?

It explicitly states when to use 'date' for a single day versus 'start_date/end_date' for a range, and includes a maximum range of 31 days. This gives clear conditional guidance for parameter selection, which is more detailed than typical descriptions and directly addresses usage alternatives.

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.