Canada's Food Guide MCP Server

Create User Profile

create_user_profile

Create a user profile with demographic and physiological data for accurate EER calculations, choosing session or persistent storage as needed.

Instructions

Create a user profile for EER calculations with optional persistent storage.

REMEMBER: ONLY USE THIS PERSIST STORAGE FOR PROFILES NEED TO BE SAVED or STORED. BY DEFAULT USE VIRTUAL STORAGE!!!!!

You can ask the user if they want to save the profile or not.

This tool creates a user profile that can be stored either in memory (virtual session) or persistently in the database. Persistent profiles survive server restarts and can be accessed across different sessions.

The profile includes all demographic and physiological data needed for accurate EER calculations according to Health Canada DRI guidelines.

Use this tool when:

Setting up user profiles by sdjusting use_persistent_storage for repeated EER calculations
Creating profiles for multiple household members
Storing long-term nutrition analysis data
Building nutrition tracking applications

Input Schema

Name	Required	Description	Default
`input_data`	Yes	CreateUserProfileInput containing: - profile_id: Unique identifier for the profile - age: Age in years (1-120) - gender: "male" or "female" - height_cm: Height in centimeters (50-250) - weight_kg: Weight in kilograms (10-300) - pal_category: Physical activity level ("inactive", "low_active", "active", "very_active") - pregnancy_status: For females ("not_pregnant", "first_trimester", "second_trimester", "third_trimester") - lactation_status: For females ("not_lactating", "lactating_0_6_months", "lactating_7_12_months") - gestation_weeks: Required for 2nd/3rd trimester (1-42) - pre_pregnancy_bmi: Required for pregnancy calculations (10-50) - use_persistent_storage: True for database storage, False for session storage

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv3.0.0Nov 4, 2026

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations present, the description carries the full burden and does disclose meaningful behavior: persistent profiles survive server restarts and are accessible across sessions, while the default in-memory profile is session-scoped and lost. It omits what happens when profile_id already exists (error vs. overwrite) and whether any cleanup or auth is involved, which are meaningful gaps for a create-style mutation.

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

Conciseness3/5

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

The critical storage default is front-loaded, but it is delivered as an all-caps exclamation-laden block that reads like a shout rather than documentation, and contains a typo ("sdjusting"). The middle paragraph repeats the virtual-vs-persistent distinction already stated above, and the use-case bullets add largely generic scenarios rather than new information.

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?

An output schema exists, so return values need no explanation, and the nested input object is fully described in the schema. What remains is the storage-lifecycle semantics, which the description covers well; the notable omission is duplicate profile_id behavior, which matters for a creation tool with a caller-supplied identifier.

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?

Schema coverage is 100% and every nested field is individually documented, so the baseline is 3. The description earns an extra point by giving use_persistent_storage operational meaning the schema does not: default to virtual, persist only when the profile must be saved, and it is acceptable to ask the user which they want.

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 first sentence names a specific verb and resource ("Create a user profile") and scopes it to EER calculations with optional persistent storage, so it is distinguishable from get_user_profile, list_user_profiles and delete_user_profile. It stops short of explicitly naming those siblings, so an agent must infer the boundary from the tool names alone.

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

Usage Guidelines4/5

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

The "Use this tool when" list plus the explicit default rule (virtual storage by default, persistent only for profiles that must be saved) gives real when-to-use and when-not-to-use guidance, and even suggests asking the user. The scenario bullets (household members, nutrition tracking apps) are somewhat generic and overlap with each other, but the storage-mode guidance is genuinely actionable.

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

Deploy Server