Skip to main content
Glama
Sign In
SlingHook

SlingHook

by DylanCourtney584
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Run scenario

run_scenario
Destructive

Replays every event of a saved scenario in order to a target URL, reporting pass or fail per step against prior replays. Use it after a fix to prove a whole webhook flow works.

Instructions

Replays every event of a saved scenario, in order, from this machine to a URL (e.g. the local handler), and reports each step: status, pass or fail, and the verdict against that event's previous replay to the same URL. Use it after a fix to prove a whole flow works, not just one event. Steps go back to back unless keep_timing is set (gaps capped at 5 seconds). Each step is a real webhook delivery recorded in replay history, so it can change state in the receiving app.

Input Schema

NameRequiredDescriptionDefault
scenarioYesScenario id, from list_scenarios
target_urlYesWhere to deliver each step, e.g. http://localhost:3000/webhooks
keep_timingNoWait the recorded gap between steps, up to 5 seconds each
stop_on_failureNoStop at the first failing step

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Beyond annotations that already flag destructive and open-world behavior, the description discloses that each step is a real webhook delivery recorded in replay history and can change state in the receiving app. It also clarifies timing behavior: steps run back to back unless keep_timing is set, with gaps capped at 5 seconds.

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 front-loaded with the core action and scope, then adds usage, timing, and side-effect context without filler. Every sentence contributes operational detail an agent needs.

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?

For a multi-step, state-changing tool with no output schema, the description covers what is returned (status, pass/fail, verdict against prior replay), timing behavior, and real side effects. The remaining parameter details are fully covered by the schema.

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 all four parameters are documented in the schema. The description reinforces keep_timing semantics and target_url behavior but adds little beyond the schema and does not mention stop_on_failure.

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 states a specific verb and resource: it replays every event of a saved scenario in order to a target URL and reports per-step results. It also contrasts the scope with single-event replay, so an agent can distinguish it from replay_event without inspecting the schema.

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 a clear usage context: use after a fix to prove a whole flow works, not just one event. The alternative single-event tool is implied rather than named, so the routing signal is strong but not fully explicit.

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