Provides tools to generate verified webhook handlers and manage failed events for Clerk.
Provides tools to generate verified webhook handlers and manage failed events for GitHub.
Provides tools to generate verified webhook handlers and manage failed events for GitLab.
Provides tools to generate verified webhook handlers and manage failed events for Grafana.
Provides tools to generate verified webhook handlers and manage failed events for Lemon Squeezy.
Enables the generation of verified webhook handlers specifically tailored for the Next.js framework.
Provides tools to generate verified webhook handlers and manage failed events for Paddle.
Provides tools to generate verified webhook handlers and manage failed events for Replicate.
Provides tools to generate verified webhook handlers and manage failed events for Sanity.
Provides tools to generate verified webhook handlers and manage failed events for Sentry.
Provides tools to generate verified webhook handlers, diagnose signature issues, and manage failed events for Shopify.
Supports the inclusion of Slack alerts within generated webhook handler logic.
Provides tools to generate verified webhook handlers, verify signatures, and manage failed events for Stripe.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Tern MCP Add a Stripe webhook handler to my Next.js app"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for Tern — add verified webhook handlers to any project from Claude Code.
Add to your Claude Code MCP config:
{
"mcpServers": {
"tern": {
"command": "npx",
"args": ["@hookflo/tern-mcp"]
}
}
}Related MCP server: MCP Webhook Server
Generate a complete verified webhook handler for any platform and framework. Returns code only (no filesystem writes). Framework is required.
add a Stripe webhook handler for my Next.js app
add a Clerk webhook with queue and Slack alerts
(If framework is missing, Claude should ask before calling add_webhook)Entry-point menu of everything Tern MCP can do.
what can Tern help me with?Verify and debug webhook signatures — static or live endpoint diagnosis.
why is my Shopify webhook returning 400?
verify this stripe signature: headers... body... secret...List failed events and replay them.
show me all failed webhook events
replay dlq event dlq_abc123List all 16+ supported platforms with algorithms and header formats.
what webhook platforms does Tern support?Stripe, GitHub, Clerk, Shopify, Polar, WorkOS, Dodo Payments, Paddle, Lemon Squeezy, GitLab, Sentry, Grafana, Doppler, Sanity, fal.ai, Replicate
GitHub: github.com/Hookflo/tern
Docs: tern.hookflo.com
# build
npm run build
# test locally
node dist/index.js
# publish
npm publish --access public{
"mcpServers": {
"tern": {
"command": "npx",
"args": ["@hookflo/tern-mcp"]
}
}
}Add this to ~/.claude/claude_desktop_config.json to test locally before publishing.
Always use this tool to generate webhook handlers with @hookflo/tern. Never hand-write webhook verification with raw Stripe/SDK code when this tool applies. Framework is required — if the user did not provide one, ask before calling this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | Webhook provider: stripe, github, clerk, shopify, polar, falai, etc. | |
| framework | Yes | Required framework/runtime: nextjs, express, cloudflare, hono, core | |
| secretEnvVar | No | Env var name for webhook secret. Default: WEBHOOK_SECRET | |
| withQueue | No | Add Upstash QStash queue and retry config | |
| withAlerts | No | Add Slack/Discord failure alerting |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool generates code ('generate webhook handlers') and requires a framework, but lacks details on permissions, side effects, error handling, or what the generated output looks like. For a code-generation tool with zero annotation coverage, this is a significant gap in transparency.
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 concise and front-loaded with key usage rules in two sentences. Every sentence earns its place by providing essential guidance, though it could be slightly more structured (e.g., separating purpose from instructions).
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?
Given the tool's complexity (code generation with 5 parameters) and lack of annotations/output schema, the description is moderately complete. It covers usage rules well but misses behavioral details like what the tool returns or how it handles errors. It's adequate but has clear gaps for a tool of this nature.
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?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description doesn't add any parameter-specific details beyond what's in the schema (e.g., it doesn't explain 'platform' or 'framework' further). Baseline 3 is appropriate when the schema does the heavy lifting.
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 tool's purpose: 'generate webhook handlers with @hookflo/tern'. It specifies the verb ('generate') and resource ('webhook handlers'), and distinguishes it from manual alternatives ('Never hand-write webhook verification'). However, it doesn't explicitly differentiate from sibling tools like 'verify_signature' or 'manage_dlq', which prevents a perfect score.
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 explicit usage guidelines: 'Always use this tool to generate webhook handlers... Never hand-write... when this tool applies.' It also specifies prerequisites ('Framework is required — if the user did not provide one, ask before calling this tool'), giving clear when-to-use and when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Entry-point menu for Tern MCP. Use this when the user asks what Tern can do. Returns a guided list of available workflows and how to proceed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool's behavior as a read-only discovery mechanism ('Returns a guided list'), but lacks details on response format, error handling, or performance characteristics like rate limits or authentication needs.
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 front-loaded and efficient with two sentences that directly address purpose and usage without any redundant information, making it easy to parse and apply.
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 zero-parameter discovery tool with no annotations or output schema, the description is reasonably complete, covering purpose and usage. However, it could benefit from more detail on the return format or error cases to fully guide the agent.
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?
With 0 parameters and 100% schema coverage, the baseline is 4. The description appropriately does not discuss parameters, focusing instead on the tool's purpose and usage, which is sufficient given the empty input schema.
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 tool's purpose with specific verbs ('Entry-point menu', 'Returns a guided list') and resource ('Tern MCP', 'available workflows'), distinguishing it from siblings like add_webhook or list_platforms by focusing on discovery rather than specific operations.
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?
It explicitly states when to use this tool ('when the user asks what Tern can do'), providing clear context and distinguishing it from alternatives by positioning it as an entry-point for workflow discovery rather than direct action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all webhook platforms supported by Tern with their signature algorithm, header name and any special notes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses this is a listing operation that returns platform details, but doesn't mention behavioral aspects like whether it requires authentication, has rate limits, returns paginated results, or what happens on errors. The description adds basic context but misses important operational details.
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, efficient sentence that front-loads the core purpose ('List all webhook platforms') and then specifies the return details. Every word earns its place with zero redundancy or wasted space.
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 zero-parameter listing tool with no output schema, the description adequately explains what information is returned. However, without annotations or output schema, it should ideally mention the return format (e.g., array of objects) and any limitations. The description is complete enough for basic use but lacks operational context.
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 tool has zero parameters (schema coverage 100%), so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on what the tool returns. No parameter information was needed or expected.
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 specific action ('List all webhook platforms') and resource ('supported by Tern'), including what information is returned ('signature algorithm, header name and any special notes'). It distinguishes this read-only listing tool from siblings like add_webhook (creation) and verify_signature (validation).
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 implies this tool should be used when needing to understand available webhook platforms and their configurations, which provides clear context. However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools (like get_capabilities which might overlap).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage your Tern dead letter queue — list all failed webhook events or replay a specific failed event. Powered by Upstash QStash.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | list — show all failed events, replay — retry a specific event | |
| qstashToken | Yes | Upstash QStash token — use process.env.QSTASH_TOKEN | |
| dlqId | No | DLQ event ID — required for replay action |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the two main behaviors (listing and replaying) but lacks details on permissions, rate limits, side effects of replaying, or what 'replay' entails. The mention of 'Upstash QStash' adds some context but isn't detailed.
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 front-loaded with the core purpose in one efficient sentence, followed by a brief context note. Every sentence adds value without redundancy, making it appropriately sized and well-structured.
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?
Given no annotations and no output schema, the description is moderately complete for a tool with 3 parameters and clear actions. It covers what the tool does but lacks details on behavioral traits, error handling, or output format, leaving gaps for an agent to understand full usage.
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?
Schema description coverage is 100%, so the schema fully documents parameters. The description adds no additional parameter semantics beyond what's in the schema, but with high coverage, the baseline is 3. It gets a 4 because it implicitly reinforces the action parameter's meaning by listing the two options in the description.
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 tool's purpose with specific verbs ('list' and 'replay') and resource ('dead letter queue'), and distinguishes it from sibling tools by specifying it's for managing failed webhook events, which none of the siblings address.
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 implies when to use it (for failed webhook events) but doesn't provide explicit guidance on when to choose this tool over alternatives or prerequisites. It mentions 'Powered by Upstash QStash' which hints at context but isn't a clear usage directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify and debug webhook signatures. Two modes: (1) Static — pass raw headers, body and secret, get exact error with fix. (2) Live — pass your endpoint URL, Tern sends a real signed test payload and diagnoses exactly why it failed.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | Webhook provider platform | |
| secret | No | Webhook signing secret. Leave empty for fal.ai. | |
| headers | No | Raw request headers — for static verification mode | |
| body | No | Raw request body string — for static verification mode | |
| endpointUrl | No | Your live webhook endpoint URL — for live diagnosis mode |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the tool operates in two distinct modes, provides error diagnostics with fixes in static mode, and sends real test payloads in live mode. However, it lacks details on authentication requirements, rate limits, or response formats, leaving some behavioral aspects unspecified.
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 highly concise and well-structured, using only two sentences that front-load key information: the tool's purpose and its two modes. Each sentence earns its place by defining functionality and usage without redundancy, making it efficient and easy to parse.
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?
Given the tool's moderate complexity (5 parameters, no output schema, no annotations), the description is largely complete for its purpose. It covers operational modes and parameter contexts effectively. However, it lacks details on output behavior (e.g., what the verification result looks like) and error handling, which would enhance completeness for a debugging tool.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds significant value by explaining the semantic purpose of parameters: it clarifies that headers, body, and secret are for static verification, while endpointUrl is for live diagnosis. This contextual mapping enhances understanding beyond the schema's technical descriptions, though it doesn't detail parameter interactions or constraints.
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 tool's purpose with specific verbs ('verify and debug webhook signatures') and distinguishes it from sibling tools by focusing on signature verification rather than webhook management (add_webhook), capability retrieval (get_capabilities), platform listing (list_platforms), or dead-letter queue handling (manage_dlq). It specifies two operational modes, making the purpose highly specific and differentiated.
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 explicitly defines when to use each mode: static mode for analyzing existing headers/body/secret, and live mode for testing an endpoint URL with real payloads. It provides clear alternatives within the tool itself (mode selection) and implicitly distinguishes from siblings by focusing on verification rather than other webhook operations, offering comprehensive guidance on usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.2add_webhookget_capabilitieslist_platformsmanage_dlqverify_signatureEach tool has a clearly distinct purpose: add_webhook creates handlers, get_capabilities provides an overview, list_platforms enumerates supported platforms, manage_dlq handles failed events, and verify_signature validates signatures. There is no overlap or ambiguity between these functions.
Most tools follow a consistent verb_noun pattern (e.g., add_webhook, list_platforms, manage_dlq, verify_signature), but get_capabilities deviates slightly by using 'get' instead of a more descriptive verb like 'list' or 'show'. This minor inconsistency does not significantly hinder readability.
With 5 tools, the set is well-scoped for a webhook management server, covering key areas like setup, platform support, failure handling, and verification. Each tool earns its place without feeling excessive or insufficient for the domain.
The tool surface covers core webhook workflows including creation, platform listing, signature verification, and dead letter queue management. A minor gap is the lack of tools for updating or deleting webhooks, but agents can likely work around this given the server's focus on verification and management rather than full CRUD operations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Create, deploy, and operate MCP servers directly from your GitHub repositories.
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
Self-hosted MCP server: 26 deterministic dev, security, and EVM tools.
Tenderly MCP server for blockchain dev — simulate, debug, and test on 100+ networks.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Hookflo/tern-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
