Dayze — Life Context

Log Dream

log_dream

Log a sleep dream to the user's private Dream Diary, in their own words, not log_event or log_moment. narrative is required; dreamed_at YYYY-MM-DD or a local time (omit for last night); title, mood, lucidity (none, partial, full), people_names, places, tags, notes. ($0.10; 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": {
      "narrative": "<narrative>"
    },
    "name": "log_dream"
  }
}

Input Schema

Name	Required	Description
`mood`	No	peaceful, happy, weird, scary, sad, anxious, neutral, romantic, exciting or their own word.
`tags`	No	Tags, e.g. ["work"].
`notes`	No	Free-text note, e.g. Follow up next week.
`title`	No	Short title; taken from the narrative when omitted.
`places`	No	Place names, e.g. ["Grandma's house"].
`lucidity`	No	How lucid the dream was: none, partial or full, e.g. partial.
`narrative`	Yes	The dream in their words.
`dreamed_at`	No	YYYY-MM-DD or a local date-time. Omit for last night.
`request_id`	No	Client idempotency key (retries return original result).
`people_names`	No	Names of people involved, e.g. ["Alex Chen"].
`idempotency_key`	No	Alias for request_id.

Output Schema

Name	Required	Description
`dream`	No	dream_id, dreamed_at, title, mood, lucidity.
`account`	No	The Dayze account this data belongs to. With more than one Dayze connection, name it in the answer.
`created`	No
`message`	No
`provenance`	No	Which connector wrote the record and which connected Dayze account received it.

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedNov 9, 2026
- addedInput schema / properties / lucidity / description
```
Added value: +"How lucid the dream was: none, partial or full, e.g. partial."
```
- addedInput schema / properties / notes / description
```
Added value: +"Free-text note, e.g. Follow up next week."
```
- addedInput schema / properties / people_names / description
```
Added value: +"Names of people involved, e.g. [\"Alex Chen\"]."
```
- addedInput schema / properties / people_names / items / description
```
Added value: +"Contact name, e.g. Alex Chen."
```
- addedInput schema / properties / places / description
```
Added value: +"Place names, e.g. [\"Grandma's house\"]."
```
- addedInput schema / properties / places / items / description
```
Added value: +"Place name, e.g. Grandma's house."
```
- addedInput schema / properties / tags / description
```
Added value: +"Tags, e.g. [\"work\"]."
```
- addedInput schema / properties / tags / items / description
```
Added value: +"Tag, e.g. work."
```
AddedNov 4, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare this is a non-read-only, non-destructive, closed-world write. The description adds genuinely new behavioral facts: the entry goes to a private diary, the call costs $0.10, and an API key is required. It says nothing about duplicate handling or what happens if a dream is logged twice, though the schema's idempotency fields partly cover that.

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?

The critical routing information (what it is, what it is not) is front-loaded in the first sentence, and the cost/auth note is tucked at the end. The middle parameter list is dense and semi-colon-heavy, slightly reducing readability, but no sentence is wasted.

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 with full schema coverage and an output schema, the description supplies everything an agent needs: purpose, sibling exclusion, required field, date semantics, enumerable field values, cost, and auth. Return values are handled by the output schema, so their absence here is not a gap.

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?

Schema description coverage is 100%, so every one of the 11 parameters is already documented in the schema, including the "omit for last night" default and the lucidity enum values. The description's field list largely restates what the schema already says, so the baseline of 3 applies.

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 names a specific verb and resource ("Log a sleep dream") plus the destination ("private Dream Diary"), and explicitly distinguishes itself from two named siblings, log_event and log_moment. An agent can route between these tools without opening any 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?

It gives both a positive condition (a sleep dream, recorded in the user's own words) and explicit exclusions ("not log_event or log_moment"), which is the strongest form of routing guidance. The required-field and default-date hints further constrain correct invocation.

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.