Loading ToolBench
JustLog helps users track calories, macros, exercise, and weight. Use the provided tools to log and retrieve entries.
JustLog provides 8 tools with complete JSON Schema definitions and explicit descriptions for each tool. Naming follows verb_noun conventions (log_*, get_*, update_*, delete_*) which is good. However, several tools have structural issues: parameter descriptions are minimal (often single phrases), output schemas are not documented anywhere in the visible code, and there is no evidence of error handling guidance or recovery patterns. The update_entry tool conflates multiple resource types (food, exercise, weight) in a single schema with overlapping optional fields, violating single-responsibility principle. Profile-related tools accept open-ended string parameters (height, ideal_weight, diet, goal, lifestyle, timezone) with no enums, patterns, or format constraints, inviting hallucinated values and mismatches. Tool descriptions are present but terse (10-50 chars), missing context about when to use each tool, dependencies, and expected outcomes.
Delete a specific log entry by its sort key
Retrieve log entries for a given type and date range
Retrieve the user's profile information including timezone, height, weight goal, and diet preferences
Log an exercise entry with duration and intensity
Log a food entry with nutritional information
Log a weight entry
Update an existing log entry
Update user profile fields
get_profile has NO visible output schema. The description says 'Retrieve the user's profile information' but does not document what fields are returned, their types, or which are required. LLMs cannot plan downstream tool calls without knowing the structure.
update_profile accepts 8 open-ended string parameters (height, ideal_weight, diet, goal, lifestyle, birthdate, sex, timezone) with NO enums, patterns, formats, or constraints. Height could be '5\'10"', '178cm', 'tall', or '180', LLMs will hallucinate invalid values. Sex should be an enum [male, female]. Timezone should match IANA identifiers with a pattern constraint.
update_entry conflates three different resource types (food, exercise, weight) in a single tool with overlapping optional fields (description, calories, protein, carbs, fat, duration, value, unit, notes). This violates single-responsibility. An LLM cannot know which fields to pass for a weight update vs exercise update. Should be three separate tools: update_food_entry, update_exercise_entry, update_weight_entry.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Tool descriptions are terse (10-50 characters). 'Retrieve log entries for a given type and date range' is functional but does not explain dependencies (must know valid type enum values), limitations (does it paginate? what is the default limit?), or expected structure of returned entries. Descriptions should be 50-200 chars and explain WHAT, WHEN, and WHAT IS RETURNED.
No output schemas documented for any tool. The visible code shows input schemas only. LLMs cannot know whether get_entries returns an array of entries, a paginated object with {items, total_count, next_cursor}, or a flat object. Returning undocumented structures forces LLMs to guess at field names and types.
No error handling guidance visible. Tools do not document what errors are possible, whether they are retryable, or what the LLM should do next. For example, if update_profile rejects an invalid timezone, does it return 'Invalid timezone' or 'Value must be an IANA identifier (e.g., America/New_York)'? Without recovery guidance, agents cannot self-correct.
delete_entry is destructive but has no confirmation pattern or dry-run mode. Agents make mistakes, a resource marked with the destructiveHint annotation is not sufficient. Consider adding a confirm_delete_entry tool or a dry_run boolean parameter to preview what will be deleted.
get_entries accepts date range but no pagination parameters (page, limit, offset, cursor). If a user has 500 food entries over a date range, does the tool return all 500? No limit in description. Unbounded results blow context windows. Add limit parameter (1-100, default 20) and return total_count and next_cursor.
Parameter descriptions are often single short phrases (e.g., 'Description of the food item', 'Duration in minutes'). They do not explain constraints, valid ranges, formats, or dependencies. For 'calories', should it be an integer or float? Minimum/maximum? Null allowed? Format constraints must be in descriptions since LLMs do not read JSON Schema pattern/minimum/maximum fields reliably.