Local MCP

Daily Brief

daily_brief

Read-only

Returns a single morning briefing combining today's calendar events, overdue and due-today reminders, unread inbox email count + subjects, and — when a location is provided — today's weather. Perfect for starting each day: one call gives you everything on your plate.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`location`	No	Optional city name or 'lat,lon' to include today's weather in the brief (e.g. 'London', 'San Francisco'). Omitted if not provided.
`include_emails`	No	Include unread email summary from Mail.app (default true, skipped gracefully if Mail is not running)

Output Schema

TableJSON Schema

Name	Required	Description
`date`	Yes	Today's date (YYYY-MM-DD).
`note`	No	Onboarding enrichment shown when nothing is scheduled.
`emails`	Yes	Unread email summary (unread_count + recent_unread), or {skipped} / {error}, or null when not requested.
`events`	Yes	Today's calendar events.
`weather`	No	Today's weather (current conditions + forecast), only present when a location was provided.
`reminders`	Yes	Reminders due today or overdue.
`incomplete`	No	Sections that could NOT be read this time (each step has its own ceiling). An empty/absent list means every section was actually read; a section named here means its data is missing, NOT that it is empty.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedAug 18, 2026

addedOutput schema / properties / incomplete

Added value: +{
+  "description": "Sections that could NOT be read this time (each step has its own ceiling). An empty/absent list means every section was actually read; a section named here means its data is missing, NOT that it is empty.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

Changed2 schema fields changedJul 9, 2026

addedInput schema / properties / location

Added value: +{
+  "description": "Optional city name or 'lat,lon' to include today's weather in the brief (e.g. 'London', 'San Francisco'). Omitted if not provided.",
+  "type": "string"
+}

addedOutput schema / properties / weather

Added value: +{
+  "description": "Today's weather (current conditions + forecast), only present when a location was provided.",
+  "type": "object"
+}

First observedJun 30, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description usefully discloses that weather is included only when a location is provided, adding conditional behavior beyond the annotations.

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?

Two tight sentences with the payload front-loaded and the conditional weather clause placed at the end. The closing 'Perfect for starting each day' is mildly promotional but still carries routing value.

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 not be explained, yet the description still enumerates the brief's contents. For an aggregator with no required parameters, nothing an agent needs to call it correctly is missing.

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 both parameters are already fully documented. The description only echoes the location-to-weather dependency, adding no syntax or format detail beyond the schema, so the baseline 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?

States a specific verb and resource ('Returns a single morning briefing') and enumerates exactly what it aggregates: calendar events, overdue/due-today reminders, unread email count and subjects, and conditional weather. This cleanly distinguishes it from the many single-source siblings like list_calendar_events and list_reminders.

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?

Frames the use case clearly ('Perfect for starting each day: one call gives you everything on your plate'), which implicitly routes the agent here instead of making several sibling calls. It stops short of explicit when-not guidance or naming the individual tools it replaces.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Local MCP 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.