delimit

Official

Overview Schema Source Related Servers Discussions Admin

Delimit Notify

delimit_notify

Send one outbound notification via webhook, Slack, or email for actionable events like replies, approvals, or deployment decisions. Requires explicit operator authorization before sending.

Instructions

Send a notification (webhook / Slack / email).

When to use: for an operator-authorized notification about an outreach reply, deployment decision, approval need, or other actionable event. When NOT to use: for SIEM-class structured streaming (use delimit_siem) or multi-routing config (delimit_notify_routing).

Sibling contrast: delimit_notify_routing configures rules; delimit_notify_inbox reads inbound; this sends one outbound.

Side effects: sends a network message via webhook (JSON POST), Slack webhook, or email (SMTP). The founder reviews and replies via email — that reply is consumed by delimit_notify_inbox / delimit_inbox_daemon.

IMPORTANT - EXTERNAL ACTION BOUNDARY: This tool sends an external message. Obtain explicit authorization in the current session unless the operator's supplied policy already authorizes this notification class and destination. Never infer permission merely because the content was drafted or classified.

Channels: webhook (JSON POST), slack (webhook URL), email (SMTP). Use for: governance alerts, deployment notifications, breaking change warnings.

IMPORTANT - Email context rules: Every email must be self-contained and actionable. The recipient reads on mobile and needs to know exactly what to do without opening another app.

Subject: lead with [ACTION TYPE] bracket, include enough context to triage from inbox
Body: include WHAT happened, WHY it matters, WHAT to do next, and relevant links
Never send bare IDs or technical state without human-readable context

Input Schema

TableJSON Schema

Name	Required	Description	Default
`to`	No	Recipient email address (email only). Overrides default DELIMIT_SMTP_TO. Send to any address - leave empty for default.
`channel`	No	webhook, slack, or email.	webhook
`led_ref`	No	Optional LED-XXXX tag tying the draft to its tracking item. Surfaced in subject-line matching by the executor.
`message`	No	Notification body. Must include full context (see rules above).
`subject`	No	Subject line (email only). Use [ACTION], [INFO], [ALERT] prefix.
`draft_kind`	No	One of github_comment, social_post, ledger_done, notify_routing_update, deploy_publish_prevalidated_artifact. When set, registers a signed draft in the local SQLite registry so a future executor can match founder Ship-it replies against it.
`event_type`	No	Event category for filtering.
`webhook_url`	No	URL for webhook/slack channels.
`draft_target`	No	Where the action lands (e.g. {"repo":"x/y","issue":1}). JSON string or dict. Required when draft_kind is set.
`from_account`	No	Sender account key from ~/.delimit/secrets/smtp-all.json (e.g. 'notifications@example.com'). Email only. Optional inbox-executor binding (LED-1129 Phase 1, no auto-execution yet):.
`draft_payload`	No	The action contents (e.g. {"body": "..."} for github_comment). JSON string or dict. Required when draft_kind is set.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv4.7.9Jun 9, 2026

addedInput schema / properties / draft_kind

Added value: +{
+  "default": "",
+  "description": "One of github_comment, social_post, ledger_done, notify_routing_update, deploy_publish_prevalidated_artifact. When set, registers a signed draft in the local SQLite registry so a future executor can match founder Ship-it replies against it.",
+  "type": "string"
+}

addedInput schema / properties / draft_payload

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "The action contents (e.g. {\"body\": \"...\"} for github_comment). JSON string or dict. Required when draft_kind is set."
+}

addedInput schema / properties / draft_target

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Where the action lands (e.g. {\"repo\":\"x/y\",\"issue\":1}). JSON string or dict. Required when draft_kind is set."
+}

changedInput schema / properties / from_account / description

Previous value: -"Sender account key from ~/.delimit/secrets/smtp-all.json\n(e.g. 'notifications@example.com'). Email only."New value: +"Sender account key from ~/.delimit/secrets/smtp-all.json (e.g. 'notifications@example.com'). Email only. Optional inbox-executor binding (LED-1129 Phase 1, no auto-execution yet):."

addedInput schema / properties / led_ref

Added value: +{
+  "default": "",
+  "description": "Optional LED-XXXX tag tying the draft to its tracking item. Surfaced in subject-line matching by the executor.",
+  "type": "string"
+}

changedInput schema / properties / to / description

Previous value: -"Recipient email address (email only). Overrides default DELIMIT_SMTP_TO.\nSend to any address - leave empty for default."New value: +"Recipient email address (email only). Overrides default DELIMIT_SMTP_TO. Send to any address - leave empty for default."

Addedv4.5.5May 7, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false and destructiveHint=false, so the description carries the behavioral burden. It discloses that this sends an external network message (webhook POST, Slack, SMTP), the side effect that the founder replies by email consumed elsewhere, and critically an EXTERNAL ACTION BOUNDARY requiring explicit operator authorization. This far exceeds what annotations convey.

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?

Well-structured with clear header sections that aid navigation, and the external-action boundary is front-loaded. However, it is verbose with redundancy: the 'Channels' paragraph repeats channel types and use-cases already stated, and the founder-reply flow detail is somewhat tangential. Each section earns its place but could be trimmed.

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?

Exceptionally complete for an 11-parameter, zero-required-parameter tool with an output schema. It covers authorization requirements, channel options, email formatting standards, sibling routing, and the draft-registration behavior of draft_kind. An agent has everything needed to call this correctly.

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 baseline is 3. The description adds email-specific formatting rules (subject [ACTION TYPE] bracket, self-contained actionable body) that enrich the message and subject parameters beyond the schema, but it doesn't add per-parameter meaning for most of the 11 parameters. The schema already documents them well.

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?

Opens with a specific verb+resource: 'Send a notification (webhook / Slack / email).' It names the exact sibling it is not (delimit_siem for SIEM streaming, delimit_notify_routing for multi-routing config, delimit_notify_inbox for inbound reads), making the tool's identity unmistakable among the massive sibling list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit 'When to use' and 'When NOT to use' sections name alternatives and the conditions that select them. It also clarifies the boundary with delimit_notify_routing (configures rules) and delimit_notify_inbox (reads inbound), leaving no ambiguity about when this tool applies.

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

Deploy Server