Dayze — Life Context

Get Person Context

get_person_context

Read-only

Read-only distilled context for one owned Dayze Contact: profile fields, conversation prep (hobbies, interests, topics, strengths, frictions, boundaries from conversation_context), and recent logged interactions. Pass person_id (preferred) or name. Email/phone need pii:read; notes need include_notes=true. Same not-found for missing and non-owned contacts. Never-share contacts and interactions are omitted. Changes nothing. ($0.05; API key required)

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_person_context"
  }
}

Input Schema

Name	Required	Description
`name`	No	Contact name or alias when person_id is unknown. Ambiguous matches return candidates.
`person_id`	No	Contact UUID from get_people / resolve_person (preferred when known).
`recent_limit`	No	Most recent interactions to include (default 5, at most 20).
`include_notes`	No	Include free-text notes (default false). Contact details in notes still need pii:read.

Output Schema

Name	Required	Description
`note`	No
`count`	Yes
`query`	No
`person`	No	Distilled contact card (notes/email/phone gated).
`account`	No	The Dayze account this data belongs to. With more than one Dayze connection, name it in the answer.
`message`	No
`resolved`	No
`candidates`	No
`matched_via`	No
`conversation`	No	hobbies, interests, topics, strengths, frictions, boundaries, lifestyle.
`inspect_note`	No	How to cite: link each record with its inspect_url, never a link built from an id; which record types here have no Dayze page.
`recent_count`	No
`include_notes`	No
`recent_interactions`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 10, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Adds substantial context beyond the readOnly/destructive annotations: explicit cost ($0.05), API key requirement, scope gates, and two security-relevant behaviors — 'Same not-found for missing and non-owned contacts' (prevents ownership probing) and 'Never-share contacts and interactions are omitted'. 'Changes nothing' merely restates readOnlyHint=true rather than extending it.

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-loads the core purpose and packs scope, cost, and error semantics into a compact block with no filler sentences. It is slightly telegraphic in places (parenthetical scope notes, semicolon-chained clauses), which costs a bit of readability.

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?

Covers every decision an agent needs for a 4-param read tool: identifier choice, scope requirements, opt-in for notes, omission rules, indistinguishable not-found, cost, and confirmation of no side effects. With an output schema present, the description need not explain return shapes and correctly does not.

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 all four parameters are already documented, including person_id being preferred and name returning candidates. The description's parameter-related additions (person_id preferred, include_notes gate, pii:read for details in notes) largely restate schema text, so the baseline of 3 applies.

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?

States a specific verb and resource ('read-only distilled context for one owned Dayze Contact') and enumerates the content categories included (profile fields, conversation prep, recent interactions). It does not name or contrast with the overlapping siblings (get_person_interactions, get_context_pack), so an agent must infer the aggregation boundary itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete invocation conditions: 'Pass person_id (preferred) or name', 'include_notes=true' for notes, and pii:read for email/phone. What is absent is any when-to-use-this-vs-alternatives guidance, particularly against get_person_interactions or get_context_pack, which cover similar-sounding ground.

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.