Skip to main content
Glama
Sign In

Dutify

by ai.dutify.mcp
OverviewDiscussionsAdmin

pm_replay_webhook_delivery

Destructive

Re-send a specific past delivery to the webhook URL. Useful when the subscriber was down during the original attempt window or you need to re-trigger downstream processing. A replay re-sends the stored payload bytes, so it keeps the original envelope id and eventId: subscribers MUST treat a repeated eventId as a duplicate. The X-Webhook-Delivery header carries the new delivery id of the replay, so it differs from the envelope id. Every replay re-checks access first: a wiki or feature-request event whose item the webhook creator can no longer see is not replayed (404). API-key scope: webhooks:write.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "webhookIdentifier": "<webhookIdentifier>",
      "deliveryIdentifier": "<deliveryIdentifier>"
    },
    "name": "pm_replay_webhook_delivery"
  }
}

Input Schema

NameRequiredDescriptionDefault
accountNoMulti-account auth only: name of the account from X-Dutify-Accounts to use for this call. Ignored in single-account mode (X-API-Key header). When multiple accounts are configured and this is omitted, the call fails with ACCOUNT_REQUIRED listing the available names. list_accounts never requires a selection.
workspaceNoWorkspace identifier or exact name for this call. Overrides the configured workspace. For personal keys, discover candidates with list_workspaces and select explicitly. Does not change other calls or expand a workspace key's access.
webhookIdentifierYesWebhook identifier
deliveryIdentifierYesDelivery (attempt) identifier to replay

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing that the stored payload bytes are re-sent with the original envelope id and eventId, that subscribers must dedupe on repeated eventId, that X-Webhook-Delivery carries a new delivery id, that access is re-checked and can yield a 404, and that the api-key scope is webhooks:write. This is exactly the non-obvious side-effect information an agent needs for a destructive, non-idempotent call.

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

Conciseness4/5

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

Purpose is front-loaded in the first sentence, and the following sentences each add distinct information (rationale, dedupe warning, header semantics, access recheck, scope). It is dense but every sentence earns its place; slightly long for four parameters.

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?

Covers purpose, trigger conditions, payload/identity semantics, failure mode (404 with access recheck), and authorization scope, which is everything an agent needs absent an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema carries the parameter definitions; the description still adds value by clarifying what deliveryIdentifier selects (a stored attempt with preserved payload bytes) and how the replay's identity relates to the original envelope id. It does not distinguish webhookIdentifier vs deliveryIdentifier at the parameter level.

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 and resource ('Re-send a specific past delivery to the webhook URL'), making it distinguishable from listing deliveries or firing a test webhook. The word 'specific' plus the required deliveryIdentifier makes the scope unambiguous.

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 clear conditions for use: subscriber was down during the original attempt window, or downstream processing needs re-triggering. It does not explicitly name alternative siblings such as pm_test_webhook or pm_list_webhook_deliveries, so the agent must infer 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.

All Dutify toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources