Dayze — Life Context

Add Food Visual Reference

attach_food_visual_reference

After the user asks to save an illustration, attach transferable image bytes to an EXISTING food_id as Visual reference, not a photo of the actual meal. Private; preserves actual photos and meal time. Requires request_id and confirmed=true. ChatGPT must pass image via its file bridge; a rendered image or local file ID alone cannot be attached. Only attached=true with verified stored bytes/readback confirms persistence. Retry the SAME request_id after uncertainty; never log another meal. ($0.15; API key required)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "food_id": "<food_id>",
      "confirmed": "<confirmed>",
      "request_id": "<request_id>"
    },
    "name": "attach_food_visual_reference"
  }
}

Input Schema

Name	Required	Description
`url`	No	HTTPS image URL for expert API clients only; SSRF checks apply.
`image`	No	ChatGPT chat attachment. Prefer this for images from the conversation; API clients may still use image_base64 or url.
`source`	No	chatgpt_generated or illustration; illustration stores as external_illustration.
`food_id`	Yes	Existing Food Diary food_id from log_food or find_image_target. Never create a duplicate meal to attach an image.
`confirmed`	Yes	true only after the user requested saving this image to this meal.
`generator`	No	Generator if known; do not invent.
`mime_type`	No	MIME type of the image, e.g. image/png.
`request_id`	Yes	Client idempotency key; a retry with the same key returns the original result, e.g. req_2026-10-17_001.
`generated_at`	No	ISO time if known; do not invent.
`image_base64`	No	Actual image bytes, for clients without the ChatGPT file bridge.
`idempotency_key`	No	Alias for request_id.

Output Schema

Name	Required	Description
`role`	No
`source`	No
`account`	No	The Dayze account this data belongs to. With more than one Dayze connection, name it in the answer.
`food_id`	No
`asset_id`	No
`attached`	No
`view_url`	No
`provenance`	No	Which connector wrote the record and which connected Dayze account received it.
`inspect_url`	No
`inspect_note`	No	What inspect_url opens. Never quote the record id.
`verification`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 9, 2026

addedInput schema / properties / mime_type / description

Added value: +"MIME type of the image, e.g. image/png."

addedInput schema / properties / request_id / description

Added value: +"Client idempotency key; a retry with the same key returns the original result, e.g. req_2026-10-17_001."

Changed2 schema fields changedNov 8, 2026

addedInput schema / properties / source / description

Added value: +"chatgpt_generated or illustration; illustration stores as external_illustration."

changedInput schema / properties / source / enum

Previous value: -[
-  "chatgpt_generated",
-  "external_illustration"
-]New value: +[
+  "chatgpt_generated",
+  "external_illustration",
+  "illustration"
+]

AddedNov 7, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Well beyond the annotations: it discloses privacy, that actual photos and meal time are preserved, that a rendered image or local file ID alone cannot be attached, that only attached=true with verified readback confirms persistence, and that it costs $0.15 with an API key. The annotations only cover the generic write/openWorld profile. The only reason this is not a 5 is that the readback/verification claim is asserted without saying what a failed or partial response looks like.

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

Conciseness4/5

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

Purpose is front-loaded and nearly every clause carries operational weight (privacy, idempotency, verification, cost). It is written as one long run-on string, though, so the retry and verification rules blur together with the pricing note rather than being separable at a glance.

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?

For an 11-parameter mutation tool with a nested object, this covers trigger, prerequisites, transport constraints, idempotent retry, persistence verification, privacy guarantees, auth, and cost. An output schema exists, so return format need not be spelled out, and it still adds the one return detail that matters (attached=true plus readback).

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%, so baseline is 3, but the description adds real meaning: it declares request_id and confirmed=true as hard prerequisites and explains the idempotent retry semantics of request_id, plus the constraint that image bytes must arrive through the file bridge rather than a local file ID. That constrains how the nested image payload will actually be honored, which the schema alone does not convey.

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?

States a specific verb and resource ('attach transferable image bytes to an EXISTING food_id') and immediately disambiguates the scope: 'as Visual reference, not a photo of the actual meal.' That distinction separates it from the photo-attachment sibling without requiring the agent to open either schema.

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?

Gives an explicit trigger ('After the user asks to save an illustration'), explicit exclusions (not an actual meal photo, never create a duplicate meal to attach), required preconditions (request_id and confirmed=true), and a failure-recovery rule (retry the SAME request_id after uncertainty). Nothing about when to call it versus a near-neighbor is left to inference.

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

All Dayze — Life Context tools Inspect

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.