Skip to main content
Glama

webhook_register

Register an outbound webhook that fires on OmniFocus state changes. Supports triggers for task completion, creation, or project status changes, with optional filters and HMAC signature verification.

Instructions

Register an outbound webhook that fires when an OmniFocus state change matches the supplied trigger. Off by default — requires OMNIFOCUS_WEBHOOKS_ENABLED=1 in the environment, mirroring the raw-script gating. URLs must use https:// (http:// is rejected at registration). An optional secret enables HMAC-SHA256 signature verification by the receiver via X-OmniFocus-Signature: sha256=; the secret is stored on disk only and is never echoed back through any tool response. Do NOT use this to call this MCP server itself — webhooks are outbound only. Returns { webhook: WebhookSummary } where the summary omits both URL and secret. Side effects: writes to the registry config file at ~/Library/Application Support/omnifocus-mcp/webhooks.json (mode 0600). Example: webhook_register({ name: "slack-billing", url: "https://hooks.slack.com/services/...", trigger: { on: "task-completed", filter: { tagId: "tag_xyz" } } })

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesOutbound HTTPS URL. http:// is rejected at registration (per ADR-0016 §4b).
nameYesStable name for the webhook. Unique within the registry; used as the lookup key. ≤64 chars, no whitespace.
secretNoOptional HMAC seed (8–256 chars). When set, every delivery includes an X-OmniFocus-Signature: sha256=<hex> header so the receiver can verify authenticity. Stored on disk only; never echoed.
triggerYesWhat triggers a webhook fire — one of task-completed, task-created, or project-status-changed. Each variant accepts an optional filter narrowing which entities count.
Behavior5/5

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

With no annotations, the description fully discloses behavioral traits: the environment gating, URL rejection, secret handling (never echoed, stored on disk only), return value omission, side effects (writes to config file with mode 0600), and the outbound-only nature. This is highly transparent.

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?

The description is concise and well-structured, starting with the core purpose, followed by constraints, behavioral details, side effects, and an example. Every sentence adds value, and it is appropriately front-loaded.

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?

Given the complexity of 4 parameters and nested trigger objects, the description covers all essential aspects: purpose, prerequisites, behavioral details, side effects, return value, and an example. It is complete for an agent to correctly invoke the tool.

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 description adds limited new meaning beyond the schema. It provides an example and contextual warnings (e.g., 'Do NOT use this to call this MCP server itself'), but the parameter descriptions are already detailed in the schema.

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 description clearly states the tool's purpose: 'Register an outbound webhook that fires when an OmniFocus state change matches the supplied trigger.' It uses specific verbs and resources, and distinguishes from sibling tools like webhook_delete, webhook_list, and webhook_test.

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 provides context on when to use the tool, including the environment variable requirement and the HTTPS-only URL constraint. It warns against using it to call the MCP server itself. However, it does not explicitly compare to other webhook tools or specify when not to use it.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/torsday/omnifocus-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server