Skip to main content
Glama
Canada's Food Guide MCP Server

Canada's Food Guide MCP Server

Simple Math Calculator

simple_math_calculator

Calculates arithmetic expressions with variables to total recipe nutrition, scale servings, convert units, and evaluate energy requirements—use it instead of manually summing values.

Instructions

Perform simple mathematical calculations with string variables.

!!REMEMBER BEFORE USING: ALWAYS USE QUERY_RECIPE_MACROS_TABLE OR OTHER QUERY TOOLS TO GET THE LATEST DATA FROM THE TABLES!!"

This tool allows you to evaluate mathematical expressions containing variables. It supports basic arithmetic operations (+, -, *, /, **, %) and common math functions.

CRITICAL for CNF nutrition calculations: This is the ONLY tool to use for calculating nutrition totals. Never manually sum values from JSON data.

Supported operations:

  • Basic arithmetic: +, -, *, /, ** (power), % (modulo)

  • Parentheses for grouping: (expression)

  • Variables: any valid Python identifier (letters, numbers, underscores)

Use this tool when:

  • Calculating EER equations with specific values

  • CNF nutrition calculations - summing calories, macros across ingredients

  • Recipe per-serving calculations - dividing totals by serving count

  • Scaling recipe quantities

  • Converting units

  • Any mathematical operation with known variables

CNF Nutrition Examples:

  • Total calories: "(206 * 565 / 100) + (885 * 10 / 100) + (22 * 450 / 100)"

  • Per serving: expression="total_calories / servings", variables={"total_calories": 1437, "servings": 5}

  • Scaling: expression="original_amount * scale_factor", variables={"original_amount": 100, "scale_factor": 1.5}

  • EER comparison: expression="recipe_calories - eer_requirement", variables={"recipe_calories": 287, "eer_requirement": 2000}

TEMP_RECIPE_MACROS Calculation Examples:

  • Conversion factor: expression="recipe_amount / cnf_serving", variables={"recipe_amount": 10.0, "cnf_serving": 5.0} # = 2.0

  • Scaled calories: expression="cnf_calories * conversion_factor", variables={"cnf_calories": 22.0, "conversion_factor": 2.0} # = 44.0

  • Recipe total from cache: expression="honey_cals + oil_cals + salmon_cals", variables={"honey_cals": 44.0, "oil_cals": 80.0, "salmon_cals": 200.0}

General Examples:

  • EER calculation: "662 - (9.53 * age) + (15.91 * weight) + (539.6 * height)"

  • Unit conversion: "cups * 240" (cups to ml)

  • Percentage: "part / total * 100"

Input Schema

NameRequiredDescriptionDefault
math_inputYesContains expression string and variables dictionary

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.0.0

TDQS

A4.4/5.0
Behavior4/5

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

While no annotations are provided, the description effectively communicates behavioral constraints by listing supported operations (+, *, /, **, %, etc.) and variable naming conventions. It defines the functional scope of the tool very clearly.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Despite its incredible detail, the definition is excessively verbose and repetitive. The multiple sections of examples and repeated warnings make the definition overwhelming and poorly structured for quick reference.

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?

The definition is highly complete, offering multiple concrete, runnable examples across different domains (CNF, recipe scaling, general math), which leaves little ambiguity for the agent.

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?

With 100% schema coverage, the description provides context rather than correcting schema omissions. It successfully explains the semantics of the input fields, such as variables being 'any valid Python identifier.'

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 clearly defines the tool's purpose as performing calculations with string variables, and it provides strong context for when it should or should not be used (e.g., 'ONLY tool to use for calculating nutrition totals').

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 provides extensive guidance on use cases (CNF calculations, per-serving calculations, EER equations) and gives explicit instructions on process (e.g., 'NEVER manually sum values from JSON data').

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