Dayze — Life Context

Correct Learned Fact

correct_learned_fact

Replace an owned learned fact’s value and set provenance (default stated → current). Contact-backed facts must be fixed in Contacts. Supply request_id for safe retries. ($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": {
      "fact_id": "<fact_id>",
      "value": "<value>",
      "request_id": "<request_id>"
    },
    "name": "correct_learned_fact"
  }
}

Input Schema

Name	Required	Description
`value`	Yes	Corrected fact value.
`fact_id`	Yes	Learned fact id, e.g. 3f2a1b4c-8d9e-6f01-c2b3-c4d5e6f70809.
`provenance`	No	Default stated.
`request_id`	Yes	Client idempotency key; a retry with the same key returns the original result, e.g. req_2026-10-17_001.
`idempotency_key`	No	Alias for request_id.

Output Schema

Name	Required	Description
`ok`	Yes
`code`	No
`fact`	No
`error`	No
`account`	No	The Dayze account this data belongs to. With more than one Dayze connection, name it in the answer.
`provenance`	No	Which connector wrote the record and which connected Dayze account received it.
`recordState`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 9, 2026

addedInput schema / properties / fact_id / description

Added value: +"Learned fact id, e.g. 3f2a1b4c-8d9e-6f01-c2b3-c4d5e6f70809."

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."

AddedNov 9, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Beyond the annotations (readOnly=false, destructive=false, openWorld=false), the description discloses cost ($0.10), an API key requirement, the retry/idempotency contract, the provenance default (stated → current) and the edge case where the tool cannot be used at all. These are the behavioral facts annotations cannot express.

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?

Four tight clauses, front-loaded with the action, then constraint, idempotency and cost. Nothing is redundant, though the parenthetical cost/auth tail is crammed and could be its own short sentence for scannability.

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?

An output schema exists, so return values need no explanation. For a paid mutation with a redirect case and an idempotency key, the description covers cost, auth, retry safety and the unsupported case — everything needed to invoke it correctly.

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 the schema already documents value, fact_id, provenance, request_id and the idempotency_key alias. The description restates provenance defaulting and request_id retry semantics rather than adding new meaning. Baseline 3 is appropriate when the schema carries the parameter burden.

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 names a specific verb and resource: 'Replace an owned learned fact's value'. Ownership ('owned') and the provenance side-effect are stated, which distinguishes it from a generic fact update. It does not explicitly name confirm_learned_fact or reject_learned_fact as the non-editing alternatives, so sibling differentiation is implicit rather than explicit.

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?

It gives a concrete when-not rule — contact-backed facts must be corrected in Contacts rather than here — which is exactly the kind of routing guidance an agent needs. It also states when request_id matters (safe retries). It stops short of naming the sibling tools that confirm or reject a fact instead of correcting it.

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.