Skip to main content
Glama
Sign In

CoKarTa

by com.cokarta.app
OverviewDiscussionsAdmin

Log meal

log_meal

Logs a meal in the person's diary with its foods and amounts, or adds foods to a meal already logged. Foods from their catalog are scaled from the values stored for them.

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

Input Schema

NameRequiredDescriptionDefault
dateNoOptional day in YYYY-MM-DD. Defaults to today.
timeNoOptional clock time in HH:MM, ONLY when the user said one.
itemsNoThe foods eaten in this meal, one object each.
titleNoThe dish as the user named it — 'Tortilla francesa', never the meal slot ('Cena': that goes in meal_type). A food of THEIR OWN CATALOG in this meal is written exactly as their catalog spells it: 'Yogur natural proteico, plátano y Galletas (Gullón)', because the diary marks a catalog food in the title only where its full name reads there letter for letter. A favourite dish, by its exact name. Required to create; ignored with entry_id.
dishesNoFavourite dishes eaten in this meal, from list_foods, copied in food by food. The reply gives each food its item_id: a change for this one day ('sin café') is edit_diary or delete_record after.
entry_idNoAn entry already in the diary, from read_diary, to add the items to instead of creating one.
meal_typeNoOptional, one of: breakfast, lunch, snack, dinner. Left out, a favourite dish's own type is used.
descriptionNoOptional note on the meal: how it sat, where they were, the company — anything that is not the food itself. What they ate goes in the title, never here.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already establish that this is a non-readonly, non-destructive, non-idempotent write. The description adds useful behavior—catalog foods are scaled from stored values and an existing meal can be appended to—but it does not discuss duplicate handling, permissions, or side effects beyond that.

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 front-loaded sentences with no filler: first the core logging/append action, then the catalog-scaling behavior. Every sentence adds relevant meaning.

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?

For a complex write tool, the description gives enough high-level context for selection and basic invocation, while the fully described schema and annotations carry the detailed parameter and safety rules. It omits explicit mention of dishes, title requirements, and output behavior, but those are well covered in the schema.

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%, so the schema already explains parameters such as entry_id, items, values_source, and food_id in depth. The description mentions 'foods and amounts' and catalog scaling but adds little parameter-level meaning beyond the schema.

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

Purpose4/5

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

The description states a specific verb and resource—'Logs a meal in the person's diary'—and covers both creating a meal and appending foods to an already logged meal. It is clear, though it does not explicitly name the sibling tools such as edit_diary or delete_record that it differs from.

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

Usage Guidelines3/5

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

Usage is implied: log foods and amounts, or add foods to an existing meal. The description does not explicitly say when to choose it over edit_diary or delete_record, nor does it mention prerequisites such as looking up foods with list_foods; those details appear only in schema fields.

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

All CoKarTa toolsInspect
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