Dayze — Life Context

Add Visual Reference

attach_visual_reference

After explicit permission, save transferable image bytes as a private Visual reference on an existing event, Inventory item or contact. Never a real photograph, cover, avatar or evidence. Preserves existing photos. Find entity_id with find_image_target. No bytes means failure; attached=true requires stored-byte and same-record readback. Retry the SAME request_id. ($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": {
      "entity_type": "<entity_type>",
      "entity_id": "<entity_id>",
      "confirmed": "<confirmed>",
      "request_id": "<request_id>"
    },
    "name": "attach_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.
`confirmed`	Yes	true only after the user requested saving this image to this meal.
`entity_id`	Yes	Existing entity_id from find_image_target or its create receipt. Never create a duplicate for an image.
`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.
`entity_type`	Yes	Type of the record the id refers to, e.g. event.
`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
`account`	No	The Dayze account this data belongs to. With more than one Dayze connection, name it in the answer.
`asset_id`	No
`attached`	No
`provenance`	No	Which connector wrote the record and which connected Dayze account received it.
`inspect_url`	No	The Dayze page that shows the saved record.
`inspect_note`	No	What inspect_url opens. Never quote the record id.
`verification`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 9, 2026

addedInput schema / properties / entity_type / description

Added value: +"Type of the record the id refers to, e.g. event."

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.3/5.0

Behavior4/5

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

Goes well past the annotations by disclosing cost ($0.15), API-key requirement, non-destructive merge behavior (preserves existing photos), the hard failure mode when no bytes are present, a readback/stored-byte verification rule for attached=true, and idempotent retry semantics on request_id. The annotations already cover the safety profile, and the description adds real operational context on top; only rate limits or multi-reference limits are unstated.

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?

Front-loaded with the permission gate and purpose, then packed with constraints; nearly every clause carries an operational rule. The telegraphic, fragment-heavy phrasing and the parenthetical cost/auth tail cost it a point versus a fully polished definition.

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?

For a 12-parameter, nested-object mutation tool with an output schema, this covers gating, failure behavior, idempotency, verification and cost. A minor gap is the entity_type enum saying 'person' while the description says 'contact', and no statement about how many references may exist per record.

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 the baseline is 3, but the description adds genuine meaning: it tells the agent to source entity_id from find_image_target and to retry with the SAME request_id after a failure, which clarifies the intent of both required parameters beyond the schema text. It says nothing extra about url/image_base64/image selection precedence, which the schema already handles.

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?

Names a specific verb and resource (save image bytes as a private Visual reference) and pins the scope to an existing event, inventory item or contact. It also draws explicit negative boundaries (never a photograph, cover, avatar or evidence), which lets an agent separate it from the photo/asset attachment siblings without opening another schema.

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?

Gives clear preconditions: explicit permission from the user, confirmed=true only after the user asked to save this specific image, and points to find_image_target for obtaining entity_id. What is missing is a direct contrast with the closest sibling, attach_food_visual_reference or attach_asset, so the agent must infer which attach tool applies to a given medium.

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.