Dayze MCP gives AI agents access to notable-people knowledge packs and personal life-context data via pay-per-call tools.
Search notable people by name, occupation, or slug (notable_search)
Get notable person profiles with bio, timeline, and metadata (notable_profile)
Fetch notable knowledge packs including life-in-days, similar people, and birthday peers (notable_pack)
Get premium high-quality packs guaranteed above a quality bar (notable_pack_premium)
Access authenticated user's life context with identity, events, mood, inner circle, and social edges (get_life_context, get_context_pack)
Export life graph with person nodes and connection edges (get_life_graph)
Explore person neighborhoods around a specific person_id (get_person_neighborhood)
Retrieve calendar events for today, week, month, year, or decade (get_events)
List user contacts from personal, online, or imported sources (get_people)
Search agent memories semantically or chronologically (get_memories)
View expense summaries and cashflow (get_expenses)
View habit trackers and streaks (get_trackers)
Run semantic life search across events, people, and memories (search)
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Dayze MCP show me the life-in-days for Albert Einstein"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Life Context for AI agents — reference Life Context Protocol (get_context_pack) plus public notable-people packs.
Install / try on Smithery: https://smithery.ai/servers/polaris/dayze
This repo is a Cursor Plugin (v1.14.0): .cursor-plugin/plugin.json, skills/dayze-life-context/, URL-only root mcp.json, plus Codex/ChatGPT metadata in .codex-plugin/ and .mcp.json.
Publish to Cursor Marketplace: submit https://github.com/gohluke/dayze-mcp at https://cursor.com/marketplace/publish (see PUBLISH.md). ChatGPT plugin is already live.
Until marketplace review lands, test locally:
mkdir -p ~/.cursor/plugins/local
ln -s /path/to/dayze-mcp ~/.cursor/plugins/local/dayzeReload Cursor (Developer: Reload Window), open Customize, and click Connect. Sign in to Dayze in the browser. Do not paste an API key — Cursor discovers OAuth from RFC 9728. Same Connect flow for Cursor desktop, Cursor web, and Grok Bot.
Docs: https://dayze.com/docs/agents
Website | |
Agents docs | |
Streamable HTTP | |
REST MCP | |
Discovery | |
Server card | |
OpenAPI | |
OAuth PRM | |
OAuth AS | |
x402scan | https://www.x402scan.com/recipient/0x4DeE3CDA6cb33b1f7A29dE1385B192F802AE3EDa/resources |
Related MCP server: cathedral-mcp
Dayze is a pay-per-call people + life-in-days API for AI agents — notable packs with day-of-life numbers, similar people, and birthday peers. Public notable_* tools need no API key; USDC on Base via x402 after the free tier.
# Streamable HTTP (JSON-RPC)
curl -X POST https://dayze.com/api/mcp \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"curl","version":"1.0"}}}'
curl -X POST https://dayze.com/api/mcp \
-H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":2,"method":"tools/list"}'
# REST (compat)
curl https://dayze.com/api/v1/mcp
curl -X POST https://dayze.com/api/v1/mcp \
-H 'Content-Type: application/json' \
-d '{"tool":"notable_pack","parameters":{"slug":"albert-einstein"}}'Timeline events include day_number (e.g. Einstein’s Nobel = Day 15,580).
Public notable_* tools: no login (x402 after free tier)
Private life-graph tools: Bearer dayze_k_… or OAuth dayze_at_…
OAuth 2.1 + PKCE + DCR for Claude / ChatGPT / Gemini agents — see https://dayze.com/docs/agents
Streamable HTTP JSON-RPC at /api/mcp (initialize, tools/list, tools/call)
REST MCP-compatible at /api/v1/mcp (GET capabilities, POST {tool, parameters})
GET /api/mcp returns discovery JSON (200); SSE sessions are not available on Netlify serverless
mcp · x402 · ai-agents · notable-people · life-in-days · knowledge-api · base · usdc
Dayze MCP is hosted at https://dayze.com/api/mcp. This repo ships a local
stdio adapter (server.mjs) so Glama can build/scan without putting a URL in CMD
(Glama rejects remote endpoints in CMD arguments).
Open https://glama.ai/mcp/servers/gohluke/dayze-mcp/admin/dockerfile
Build steps: ["npm install"]
CMD arguments: ["node", "./server.mjs"]
Click Build → wait for green → Build & Release (1.6.2)
If Glama keeps checking out an old commit, use build steps:
["git fetch origin && git checkout origin/main", "npm install"]
Prefer connecting clients directly to https://dayze.com/api/mcp (Streamable HTTP + OAuth).
Documentation and listing metadata in this repo: MIT. The Dayze product and API remain proprietary; this repo exists so directories can index a public GitHub URL.
List user expenses / cashflow summary. Requires API key. ($0.10; API key required)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, non-destructive. Description adds cost ($0.10) and API key requirement, which are useful behavioral traits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Short two-sentence description. Slight redundancy ('Requires API key' appears twice), but overall concise and front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, yet description fails to specify return type or structure (list vs summary). Vague on what the tool actually returns, leaving agent uninformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline 4 applies. Description does not need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists user expenses/cashflow summary, which is specific. However, it could more explicitly differentiate from sibling tools like get_life_context, but the purpose is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. Mentions API key requirement and cost, but no context on appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the authenticated user's current life context — identity, today's events, mood, inner circle, and social edges. Prefer get_context_pack for a full session bootstrap. Requires API key. ($0.15; API key required)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive. Description adds context about being a snapshot and the need for an API key, which is useful beyond annotations. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. First sentence clearly states the action and content. Second sentence provides usage guidance and cost/auth info. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no parameters and no output schema, but description sufficiently explains what is returned (listing the context components). Given the tool's simplicity, the description is complete and leaves no ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and the input schema is empty (coverage 100%). According to rubric, 0 params yields baseline score of 4. Description does not add parameter info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves the authenticated user's current life context, listing specific components (identity, events, mood, etc.). It distinguishes from sibling get_context_pack (mentioned in description) and other listed siblings by implying this is a quick snapshot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises preferring get_context_pack for full session bootstrap, providing a clear alternative. Also mentions 'Requires API key' as a prerequisite. However, no explicit guidance on when to use this tool over other siblings like get_people or get_trackers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List user CRM people (flat list). Each row includes contact_origin (personal|online|imported). Requires API key. ($0.10; API key required)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds beyond annotations: notes flat list, cost, auth requirement, and contact_origin field. No contradiction with annotations (readOnlyHint, etc.).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and key detail, second adds cost and auth. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description explains output includes contact_origin. Missing other potential fields but sufficient for simple list. Includes cost and auth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters (schema coverage 100% via empty schema). Description adds nothing about parameters, but baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'List' and resource 'user CRM people'. Specifies output includes contact_origin with possible values. Title 'User Contacts' reinforces purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions requirement for API key and cost ($0.10). No alternative tools or when-not-to-use scenarios needed given distinct siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Subgraph around one person_id — profile plus all declared connections. Requires API key. ($0.15; API key required)
| Name | Required | Description | Default |
|---|---|---|---|
| person_id | Yes | UUID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful context about API key requirement and cost, but does not cover rate limits or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, followed by necessary requirements. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter and no output schema, the description adequately specifies input, output (subgraph of profile and connections), and prerequisites. Could elaborate on output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with a description for person_id (UUID). The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a subgraph around a person_id, including profile and all declared connections, which distinguishes it from sibling tools like get_people and notable_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions API key requirement and cost but does not provide explicit guidance on when to use this tool versus alternatives like get_people or notable_profile.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List user trackers / habits / streaks. Requires API key. ($0.10; API key required)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds cost ($0.10) and authentication requirement (API key), providing useful context beyond annotations, though with slight redundancy.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences but repeats 'API key required' twice. While short, it could be more efficient by removing redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description mentions the resource but omits return format or pagination. Adequate for a simple list tool but lacks detail on what is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100% vacuously. The description does not need to add parameter info, matching the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List user trackers / habits / streaks,' specifying the verb 'list' and the resource, which distinguishes it from sibling tools like get_expenses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions API key requirement but provides no guidance on when to use this tool versus alternatives, nor any context for filtering or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full notable-person profile JSON by slug. Use for bio, timeline, and metadata without similar people or life-in-days context. Example slug: taylor-swift. ($0.02)
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Person slug, e.g. albert-einstein |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive. Description adds cost ($0.02) and specifies returned data (bio, timeline, metadata), complementing annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no unnecessary words: first states core function, second adds usage context and examples. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with one parameter and no output schema; description covers purpose, usage, return content (bio, timeline, metadata), and cost. Annotations provide safety hints. Fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of param 'slug' with example 'albert-einstein'. Description adds another example 'taylor-swift' but no additional semantic detail beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it provides a full notable-person profile JSON by slug, differentiating from siblings by explicitly excluding similar people or life-in-days context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use for bio, timeline, and metadata, implying when not to use (for similar people or life-in-days context), but no direct alternative names mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Semantic search across the authenticated user life graph (events, people, memories). Requires API key. ($0.15; API key required)
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Alias for query | |
| limit | No | Max results 1–50 | |
| query | Yes | Search query (primary) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly, idempotent, and non-destructive hints. The description adds beyond that: requires API key, cost ($0.15), and semantic nature. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the core purpose. Every sentence earns its place—first defines function, second adds critical cost/auth info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 3 parameters and no output schema, the description covers purpose, cost, and auth. Missing details: return format (e.g., list of objects with types) and any ordering/sorting. Still reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no extra semantic detail about parameters beyond what the schema provides (e.g., no example query or clarification of limit range).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Semantic search across the authenticated user life graph (events, people, memories)', which is a specific verb and resource. It distinguishes from siblings like get_people or get_expenses by focusing on cross-entity semantic search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs sibling tools. It mentions 'Requires API key' but does not indicate scenarios where specific retrievals are preferable or when search is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.6.2get_expensesget_life_contextget_peopleget_person_neighborhoodget_trackersnotable_pack_premiumnotable_profilesearchScored across 8 tools
Each tool targets a distinct resource or action: expenses, life context, people list, person neighborhood, trackers, notable pack, notable profile, and search. Descriptions clearly differentiate purposes, even between similar notable tools.
Naming is inconsistent: five tools use 'get_' prefix, two use 'notable_' prefix, and one is just 'search'. The 'notable_' tools do not follow verb_noun pattern, and 'search' lacks any prefix.
8 tools is well within the typical 3-15 range. The scope of personal data and notable profiles justifies each tool without being excessive.
The tool set is entirely read-only; no create, update, or delete operations are provided for any resource. Additionally, a 'get_context_pack' tool is referenced in descriptions but not implemented, creating a dead end.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Biorhythm cycles, forecasts, critical days and compatibility for AI agents, one API key.
Curated knowledge API for AI agents - skill packs, semantic search, validated patterns.
140+ data APIs for agents: finance, banking validation, geo, weather, text. One API key.
City geocoding and timezone resolution for birth data, for AI agents, one API key.
