Send a message to a human on Telegram, Discord, Slack, ntfy, email and 100+ other services (apprise URL is used once, never stored).
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | message | |
| title | No | ||
| apprise_url | Yes | apprise target URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The disclosure that the apprise URL is 'used once, never stored' adds meaningful behavioral context about data handling, which is valuable given no annotations are present. However, it omits other behavioral traits like delivery guarantees, error handling, or rate limits, so transparency is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the main action and resource, and includes the apprise URL disclosure without unnecessary words. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-param tool with no output schema and no annotations, the description covers the core purpose and a key behavioral detail, but lacks information about return behavior, delivery status, or failure modes. It is adequate for basic invocation but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some meaning by noting the apprise URL is ephemeral, but it does not explain the 'title' parameter (which has an empty schema description) or provide format details beyond the schema's terse labels. With only 67% schema coverage, the description compensates only slightly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send a message to a human') and specifies the resource (various chat services like Telegram, Discord, Slack, plus 100+ services). It does not explicitly distinguish from sibling tools, but the purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as request_approval or create_inbox. It does not mention exclusions, prerequisites, or any comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have clearly distinct purposes, but create_wakeup and delayed_delivery both schedule future webhook deliveries, and frontdoor/inbox are similar buffering mechanisms. Overall, descriptions are detailed enough to distinguish most tools.
The majority follow verb_noun snake_case, but there are exceptions like guaranteed_delivery, delayed_delivery, credit_balance, and counter_incr (abbreviation). Still, the overall pattern is readable and predictable.
45 tools is excessive for a single MCP server, likely overwhelming for an agent. While the scope is broad, many tools could be consolidated or split into multiple servers.
The tool set covers a wide range of reliability primitives (queues, checkpoints, counters, watches, approvals) with create/read/manage operations. Gaps like explicit deletes are handled via TTL or generic cancel_resource, so workflows are not dead-ended.