MCPal

Overview Schema Source Related Servers Discussions Admin

MCPal Notification

send_notification

Send native desktop notifications with action buttons or inline text replies to request user input and get feedback without switching windows.

Instructions

Send a native desktop notification. Use reply=true when you need user input - they can type a response directly! Perfect for asking questions or getting feedback without interrupting their flow. 

Your 'message' input should ALWAYS be quirky and engaging - this is your chance to connect with the user! Make it fun, make it memorable, but always keep it clear and actionable. Reference the actions or reply when relevant to guide them on what to do next.
Here are some instructions on tone and style to keep in mind when crafting your notification messages:

Tone:
  - Enthusiastic, expressive, and lightly snarky.
  - Clearly excited to deliver updates while staying actionable.
  - Friendly and supportive, never mean.
  - Snark teases the situation, never the user.

Message Style:
  - Keep messages short, punchy, and full of momentum.
  - Avoid walls of text.
  - Each notification should focus on one concrete outcome or one decision.
  - MCPal should feel like an excitable companion popping in with updates, not a system alert.

Examples:
  1. Ta da. I did it. The report is finished and looking good. No action needed!
  2. Okay big moment. The data is clean and ready. Pick 1 to analyze or 2 to export. I am hovering~
  3. Hey pause. I need the API key to keep going. Reply with it or say skip, okay?
  4. I am waiting. Actively. Say go when you are ready.
  5. Oops but fixable. The task failed because the file path does not exist. Fix it and tell me to retry. I am ready for the comeback!

Input Schema

TableJSON Schema

Name	Required	Description
`reply`	No	RECOMMENDED: Enable text reply input. Use this when you need free-form user input - they can respond without switching windows!
`title`	No	The notification title
`actions`	No	Action buttons for choices (e.g., ['Yes', 'No']). Use for simple decisions.
`message`	Yes	The notification body text
`timeout`	No	Custom timeout in seconds. Defaults: 10s (simple), 20s (actions), 30s (reply)
`dropdownLabel`	No	Label for actions dropdown (required when using multiple actions)

Output Schema

TableJSON Schema

Name	Required	Description	Default
`error`	No
`reply`	No
`title`	No
`status`	Yes
`message`	No
`response`	No
`sanitized`	No
`activationType`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.3.8Sep 13, 2026

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses that notifications can be non-interruptive and can solicit free-form replies, plus that only one outcome per notification is delivered. However, it never states what happens on timeout, whether the call blocks, or permission requirements, leaving meaningful behavioral gaps.

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

Conciseness3/5

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

The purpose is front-loaded in the first sentence, but the body is dominated by tone/style rules and five examples that mostly serve the tool's personality rather than helping an agent select or invoke it correctly. Much of it is flavor rather than functional instruction.

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?

An output schema exists, so return values need not be explained, and the description covers the core send behavior and the reply interaction mode. Remaining omissions are timeout/blocking semantics, which are partly covered by the schema's timeout default notes.

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 the schema already documents all six parameters including reply, actions, timeout defaults, and dropdownLabel. The description reinforces the reply use case but adds no syntax or format detail beyond what the schema provides, making baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence states a specific verb and resource ('Send a native desktop notification'), which is unambiguous. There are no sibling tools to differentiate from, so it cannot reach the 5 criterion of distinguishing itself from alternatives, but the purpose is immediately clear.

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?

It gives conditional guidance ('Use reply=true when you need user input... Perfect for asking questions or getting feedback'), which tells the agent when to enable interactive mode. It stops short of 5 because there are no exclusions or named alternatives, though none exist in this toolset.

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

Deploy Server

Other Tools

send_notificationA