Reflecto

Send notification

send_notification

Send a push notification to the user's own paired devices (their phone and desktop running Reflecto). Use this when the user explicitly asks to be notified, pinged, or alerted, or asks you to let them know when a long-running task finishes. The notification reaches the user even when they are away from this chat. Do not use it for routine replies that belong in the conversation.

Input Schema

TableJSON Schema

Name	Required	Description
`ttl`	No	Seconds to keep the message queued if undelivered. The server floors fractions and clamps to [0, 259200] (72h), so no client-side bound is enforced here.
`url`	No	http(s) link for the notification. Opens on tap on Android; the desktop extension does not surface links in v1, so prefer an Android target when the link matters.
`tags`	No	Up to 5 short labels; extra entries are dropped with a warning.
`title`	No	Headline shown above the body. Server cap: 100 bytes.
`device`	No	Which devices to notify. Prefer the reliable values: 'all' (default), 'phone'/'mobile', or 'desktop'. A comma-separated list of custom device labels also works; call list_devices first to discover the exact labels (when that tool is available). To reach EXACTLY one device, pass its `deviceId` from list_devices instead of its label — labels are not unique, and a label shared by two devices delivers to both. An unknown label is skipped with a warning rather than failing — use the class names above unless the user named a specific device.
`actions`	No	Up to 3 action buttons; extra entries are dropped with a warning.
`message`	Yes	Notification body as plain text — write quotes and newlines literally, never JSON-escape them (no \" or \n sequences; the transport handles encoding). Required. Server cap: 1500 bytes UTF-8.
`priority`	No	Delivery priority; 'default' and above wake the device. Defaults to 'default'.
`url_title`	No	Display text for `url`. Only rendered when `url` is also set (Android only in v1).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes
`warnings`	Yes
`delivered_to`	Yes

TDQS

A4/5.0

Behavior3/5

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

Annotations already carry the mutation and non-idempotency profile (readOnlyHint=false, idempotentHint=false). The description adds useful scope context—the notification reaches the user even away from the chat—but does not disclose delivery guarantees, failure behavior, or rate limits. With annotations covering the basic safety profile, a 3 reflects the added but limited behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four targeted sentences front-load the core purpose, then provide usage triggers, a key behavioral trait, and an exclusion. There is no filler or repetition of schema details; every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the 9-parameter schema and existing output schema, the description covers purpose, scope, usage, and an important delivery behavior. It could be slightly more complete by referencing sibling tools (e.g., list_devices) for device targeting, but the schema already handles that detail, so the description is strong overall.

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%, and every parameter (ttl, url, tags, title, device, actions, message, priority, url_title) already has a semantic description. The tool description itself adds no parameter-specific meaning, so it does not need to compensate; 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?

The first sentence names a specific verb and resource: 'Send a push notification to the user's own paired devices (their phone and desktop running Reflecto).' This clearly distinguishes it from siblings like remind_me, request_approval, and send_file by narrowing the target to the user's own devices and specifying the channel.

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?

The description explicitly states when to use the tool ('when the user explicitly asks to be notified, pinged, or alerted, or asks you to let them know when a long-running task finishes') and when not to use it ('Do not use it for routine replies that belong in the conversation'). However, it does not name alternative tools for cases like scheduling a future reminder, so it lacks a full when-not/alternatives mapping.

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

All Reflecto tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0

Disambiguation5/5

Every tool has a clearly distinct purpose: reminders (remind_me/cancel_reminder), approvals (request_approval/check_reply), notifications (send_notification), files (send_file), device info (list_devices), shared items (get_shared_items), and phone locating (find_my_phone). No two tools overlap in action or resource.

Naming Consistency5/5

All nine tools follow a consistent snake_case verb_noun pattern, e.g., cancel_reminder, send_notification, list_devices. There are no deviations or mixed conventions.

Tool Count5/5

Nine tools is well-scoped for a phone-communication server. Each tool addresses a distinct functional need without redundancy or bloat, making the set feel purposeful and easy to navigate.

Completeness5/5

The surface covers the essential lifecycle for its domain: scheduling and canceling reminders, requesting and polling approvals, sending notifications and files, reading user-shared items, listing devices, and locating the phone. No obvious gaps or dead ends exist.

Resources

Need Help?