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

Canada's Food Guide MCP Server

by Aryan-Jhaveri
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Create Temp Nutrition Session

create_temp_nutrition_session

Creates a temporary nutrition session for recipe and nutrition data only when no existing session fits, helping prevent duplicate work and support cleanup management.

Instructions

⚠️ CHECK EXISTING SESSIONS FIRST! Create temporary nutrition session only if needed.

🚨 CRITICAL: ALWAYS run list_temp_sessions() BEFORE creating new sessions!

Why check first?

  • Avoids duplicate sessions for same work

  • Saves time by reusing existing recipe data

  • Prevents confusion with multiple similar sessions

🎯 EFFICIENT WORKFLOW:

1. list_temp_sessions() ← ALWAYS CHECK FIRST!
2. Found existing session? → Reuse it (more efficient)
3. Session has old data? → Use cleanup_temp_sessions() to clean
4. No suitable session? → Then create new one with this tool

✅ WHEN TO CREATE NEW SESSION:

  • No existing sessions found

  • Existing sessions are for different recipes/work

  • Need fresh start after cleaning old sessions

❌ AVOID CREATING IF:

  • Session already exists for your recipe

  • You haven't checked existing sessions first

NEXT STEPS after creating session:

  1. Use simple_recipe_setup() for integrated recipe data transfer

  2. Use bulk SQL operations instead of individual tool calls

What this creates:

  • Session tracking record for cleanup management

  • Temporary table space ready for recipe and nutrition data

  • Better persistence than in-memory virtual sessions

  • Automatic cleanup capabilities

Input Schema

NameRequiredDescriptionDefault
session_idYesUnique identifier for the nutrition analysis session

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.0.0

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It discloses what is created (session tracking record and temporary table space), persistence benefits, and cleanup capabilities, but it omits key mutation details such as duplicate session_id behavior, permissions, idempotency, and failure modes.

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?

The description is heavily padded with repeated all-caps warnings, emojis, and workflow text for a one-parameter tool whose schema is fully documented. The numbered next-steps list is also malformed, skipping from 1 to 3, and much of the content repeats the same 'check first' instruction.

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?

Given the low complexity, one parameter, and an output schema, the description covers the essentials: when to create, what gets created, and what to do next. It leaves some edge cases undocumented, such as duplicate session IDs, but the core context an agent needs is present.

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?

The input schema has 100% description coverage for session_id, so the baseline is 3. The description does not add format, uniqueness, or collision semantics for session_id beyond what the schema already provides.

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: create a temporary nutrition session, and it explains what gets created (a tracking record and temporary table space). It partially differentiates from siblings by contrasting with in-memory virtual sessions, though it does not explicitly name create_virtual_recipe_session as the alternative.

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 gives explicit when-to-use and when-not-to-use rules, including an 'ALWAYS' prerequisite to call list_temp_sessions first and guidance to reuse existing sessions. It also names cleanup_temp_sessions as the alternative when old data exists, so the agent has a clear decision path.

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

Deploy Server

Other Tools