Dayze — Life Context

Get Pending Replies

get_pending_replies

Read-only

Pending Replies (Inbox): the replies the user owes ('who do I owe a reply?'), newest first, or one by reply_id. status: unsent (default; pending + snoozed), sent, dismissed, all. Filter by person_name or person_id. Each reply has reply_id, person_name, person_id (null when unlinked), draft, summary, channel, category, source ids, status, state (unsent | sent | dismissed) and due (owed now; false while snoozed until snooze_until). Read-only. ($0.05; API key required)

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	1-200, default 50.
`status`	No
`reply_id`	No	Read one reply (ignores the filters).
`person_id`	No
`person_name`	No

Output Schema

TableJSON Schema

Name	Required	Description
`count`	Yes
`status`	Yes	The filter applied: unsent, sent, dismissed or all.
`app_url`	No
`has_more`	Yes
`pending_replies`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 1, 2026

addedOutput schema / properties / pending_replies / items / properties / is_private
```
Added value: +{
+  "description": "Always true.",
+  "type": "boolean"
+}
```

addedOutput schema / properties / pending_replies / items / properties / visibility

Added value: +{
+  "description": "Always private: Pending Replies have no sharing setting.",
+  "type": "string"
+}

changedOutput schema / properties / pending_replies / items / required

Previous value: -[
-  "reply_id",
-  "person_name",
-  "person_id",
-  "channel",
-  "category",
-  "summary",
-  "draft",
-  "status",
-  "state",
-  "due",
-  "received_at",
-  "source"
-]New value: +[
+  "reply_id",
+  "person_name",
+  "person_id",
+  "channel",
+  "category",
+  "summary",
+  "draft",
+  "status",
+  "state",
+  "due",
+  "received_at",
+  "source",
+  "visibility",
+  "is_private"
+]

Changed1 schema field changedSep 30, 2026

addedOutput schema / properties / pending_replies / items / properties / approved_at

Added value: +{
+  "description": "PHI-427: when the owner approved the draft and opened it in Gmail, or null. Dayze never sends; the Gmail sync closes the reply when the email goes out.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

Changed2 schema fields changedSep 29, 2026

addedOutput schema / properties / pending_replies / items / properties / due

Added value: +{
+  "description": "Owed now: pending, or snoozed with snooze_until passed. False while a snooze runs, and when sent or dismissed.",
+  "type": "boolean"
+}

changedOutput schema / properties / pending_replies / items / required

Previous value: -[
-  "reply_id",
-  "person_name",
-  "person_id",
-  "channel",
-  "category",
-  "summary",
-  "draft",
-  "status",
-  "state",
-  "received_at",
-  "source"
-]New value: +[
+  "reply_id",
+  "person_name",
+  "person_id",
+  "channel",
+  "category",
+  "summary",
+  "draft",
+  "status",
+  "state",
+  "due",
+  "received_at",
+  "source"
+]

AddedSep 29, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnlyHint/destructiveHint, yet the description adds real context: default ordering, that unsent means pending+snoozed, the state vs due distinction (due=false while snoozed until snooze_until), null person_id when unlinked, plus cost ($0.05) and API-key requirement. That is well beyond what the annotations supply.

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?

Dense but front-loaded: resource and query framing come first, then filters, then field/state semantics, then cost/auth. Every clause carries information; it is packed but not padded, so slightly below maximum for density.

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 a read-only list/read tool with an output schema already present, the description supplies everything needed: selection semantics, filtering, state interpretation, cost and auth. Nothing required to invoke it correctly is missing.

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 only 40% (status enum, person_id, person_name are bare), but the description compensates by explaining the status values with semantics (unsent = pending + snoozed by default) and the person filters. It adds meaning over the schema, though it does not restate limit bounds.

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?

States a specific verb and resource ('replies the user owes') with scope (newest first, or one by reply_id), and it is clearly distinguishable from siblings like create_pending_reply, update_pending_reply and resolve_pending_reply. The parenthetical framing 'who do I owe a reply?' makes the resource unambiguous.

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?

Usage context is clear: use for the inbox of owed replies, optionally narrow by status, person_name/person_id, or fetch a single item via reply_id (which ignores filters). It does not explicitly contrast with resolve_pending_reply or list-style siblings, so a 4 rather than 5.

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.