Reflecto

This connector has been deprecated

This connector has been replaced by 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.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so no contradiction; the description adds meaningful delivery context ('reaches the user even when they are away from this chat') and recipient scoping. The schema's parameter notes further disclose tolerance behavior (unknown target label skipped with a warning, extra actions dropped), which complements the annotation profile rather than repeating it.

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 short sentences, each earning its place: purpose/scope, when-to-use triggers, behavioral reach, and when-not-to-use. The verb and resource are front-loaded in the first sentence, and there is zero filler.

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 9 parameters, 100% schema coverage, four annotations, and an output schema, the description covers purpose, usage triggers, delivery reach, and exclusions. The only notable gap is not explicitly routing to related siblings (e.g., remind_me for scheduled notifications, list_devices for target discovery), though the schema's target description does point to list_devices.

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%, with rich per-parameter guidance in the schema itself (target class names vs deviceId, TTL clamping to [0, 259200], plain-text message encoding with no JSON escaping, priority wake behavior). Per the rubric this earns the baseline 3; the description's mention of 'their phone and desktop' mildly contextualizes the target parameter but doesn't meaningfully raise the score.

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 ('Send') and a specific resource ('push notification to the user's own paired devices'), scoping delivery to the user's Reflecto devices rather than arbitrary recipients. The trigger conditions ('explicitly asks to be notified, pinged, or alerted', 'long-running task finishes') set it apart from siblings like remind_me and send_file without opening their schemas.

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?

Gives explicit when-to-use conditions (explicit notify/ping/alert requests, long-running task completion) and an explicit exclusion ('Do not use it for routine replies that belong in the conversation'), which implies the conversation as the alternative. It stops short of a 5 because it doesn't name sibling alternatives such as remind_me for future-scheduled notifications or request_approval for approval flows.

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.5/5.0

Disambiguation5/5

Each tool targets a distinct action: scheduling vs cancelling reminders, pushing vs ringing a phone, sending vs receiving files/shared items, and requesting vs polling approvals. The only close pair, send_notification and remind_me, is clearly separated by immediacy vs future scheduling, and the descriptions reinforce the boundary.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern: cancel_reminder, check_reply, get_shared_items, list_devices, request_approval, send_file, send_notification. Minor possessive forms like find_my_phone and remind_me still fit the imperative verb-first style without creating confusion.

Tool Count5/5

Nine tools is well within the ideal range and each one earns its place in a personal-device integration server. The surface covers notifications, reminders, approvals, shared items, file delivery, device discovery, and phone location without redundant or filler tools.

Completeness4/5

Core workflows are covered: reminders can be scheduled and cancelled, approvals can be requested and polled, notifications can be sent, and shared items can be read incrementally. Minor gaps exist, such as no way to cancel a pending approval and no update mechanism for reminders, but these are workable and the server is explicitly stateless about some of them.

Resources

Need Help?