This MCP server manages Webhook.site tokens and captured requests. You can create, retrieve, update, and delete tokens with custom settings (default response, content type, CORS, alias, timeout, request limits, expiry, etc., and clone from existing tokens). For a given token, you can list requests (HTTP, emails, DNSHooks) with pagination, date/query filters, and sorting; get the raw body of the latest request; and delete all or filtered requests. A resource URI provides raw JSON of all captured requests for a token.
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., "@Webhook.site MCP Server list the latest requests for my webhook token"
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.
A FastMCP-based Model Context Protocol (MCP) server for the Webhook.site API. It exposes the API as MCP tools for creating, reading, updating, and managing webhook tokens and their captured requests.
Python 3.12+
uv (recommended) or pip
Related MCP server: Webhook.site MCP Server
Configure the following environment variables to authenticate and set defaults:
Environment Variable | Description |
| (Optional) Your Webhook.site API key (required for premium accounts, custom actions, and private tokens). |
| (Optional) A default Webhook.site token UUID to fall back to when not explicitly provided to tools. |
uv run server.pyYou can install this package in editable mode:
uv pip install -e .This registers the CLI command webhook-mcp.
To use this with Claude Desktop (or other MCP hosts), add the following configuration.
Using sh -c allows the use of $HOME (or other environment variables) dynamically across different user machines/setups, since most MCP hosts do not perform shell expansion on paths:
{
"mcpServers": {
"WebhookSite": {
"command": "sh",
"args": [
"-c",
"uv --directory \"$HOME/.agents/Webhook.site-FastMCP\" run server.py"
],
"env": {
"WEBHOOK_SITE_API_KEY": "your-api-key-here",
"WEBHOOK_SITE_TOKEN_ID": "your-default-token-id-here"
}
}
}
}Note: If you prefer not to use sh -c, replace "command" with "uv" and use the absolute path in the "--directory" argument.
create_tokenCreates a new Webhook.site token (URL / email address container).
Arguments:
api_key (string, optional): Overrides WEBHOOK_SITE_API_KEY.
default_status (number, optional): Default HTTP status returned to requests (200-599).
default_content (string, optional): Default response body content.
default_content_type (string, optional): Default response Content-Type (e.g. application/json, text/html).
timeout (number, optional): Seconds to sleep before responding (max 30).
listen (number, optional): Seconds to wait for "Set Response" endpoint response.
expiry (number, optional): Seconds until the token auto-expires (default: 604800, 1 week).
request_limit (number, optional): Limits request history stored (0 to 10000).
cors (boolean, optional): If true, adds CORS headers to responses.
alias (string, optional): Sets a custom token alias.
actions (boolean, optional): Enables/disables Custom Actions.
clone_from (string, optional): Token UUID to clone settings from.
get_tokenGet details and configuration of a Webhook.site token.
Arguments:
token_id (string, optional): Token UUID (defaults to WEBHOOK_SITE_TOKEN_ID).
api_key (string, optional): Overrides WEBHOOK_SITE_API_KEY.
update_tokenUpdate settings of an existing Webhook.site token.
Arguments:
Same configuration parameters as create_token + token_id.
delete_tokenDelete the Webhook.site token completely.
Arguments:
token_id (string, optional): Token UUID (defaults to WEBHOOK_SITE_TOKEN_ID).
api_key (string, optional): Overrides WEBHOOK_SITE_API_KEY.
list_requestsList captured requests, emails, and DNSHooks sent to a token.
Arguments:
token_id (string, optional): Token UUID.
api_key (string, optional): Overrides WEBHOOK_SITE_API_KEY.
sorting (string, optional): Sorting order, either "newest" or "oldest".
per_page (number, optional): Page size (default: 50, max: 100).
page (number, optional): Page number to retrieve (default: 1).
date_from (string, optional): Filter requests starting from date (yyyy-MM-dd HH:mm:ss).
date_to (string, optional): Filter requests ending at date (yyyy-MM-dd HH:mm:ss).
query (string, optional): Query string to filter results.
get_latest_requestGet the latest raw request body sent to a Webhook.site token.
Arguments:
token_id (string, optional): Token UUID.
api_key (string, optional): Overrides WEBHOOK_SITE_API_KEY.
delete_requestsDelete all or filtered requests captured by a Webhook.site token.
Arguments:
token_id (string, optional): Token UUID.
api_key (string, optional): Overrides WEBHOOK_SITE_API_KEY.
date_to (string, optional): Filter to delete requests up to this date.
query (string, optional): Filter to delete requests matching this query.
webhooksite://token/{token_id}/requestsAllows clients to retrieve the complete list of requests captured by the specified token in raw JSON format.
Create a new Webhook.site token (URL / email address container).
| Name | Required | Description | Default |
|---|---|---|---|
| cors | No | If true, adds CORS headers to responses | |
| alias | No | Sets a custom alias (regex: [a-zA-Z0-9-_]{3,32}) | |
| expiry | No | Seconds until the token auto-expires (max/default: 604800, i.e. 1 week) | |
| listen | No | Seconds to listen for response from "Set Response" endpoint (max: 10) | |
| actions | No | Enables or disables Custom Actions for the token | |
| api_key | No | Optional Webhook.site API key (or use WEBHOOK_SITE_API_KEY env var) | |
| timeout | No | Seconds to sleep before returning the response (max: 30) | |
| clone_from | No | Token UUID to clone settings from | |
| request_limit | No | Limits request history stored (0 to 10000; default: 10000) | |
| default_status | No | The default HTTP response status returned to requests (200-599) | |
| default_content | No | The default response body content | |
| default_content_type | No | The default response Content-Type (e.g. 'text/html', 'application/json') |
| Name | Required | Description |
|---|---|---|
No output 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 only states the core purpose and does not disclose side effects, authentication requirements, rate limits, or what happens on creation. For a mutation tool like create, this is a significant transparency gap.
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, front-loaded sentence with no wasted words. It is efficient and directly communicates the core function, though it could be more informative.
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?
Despite having 12 optional parameters and multiple sibling tools, the description is very thin. It does not explain typical use cases, the significance of a token, or how this tool relates to the siblings. The output schema may cover return values, but the description leaves the agent with insufficient context to understand the broader purpose.
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 input schema provides 100% coverage with descriptions for all 12 parameters, so the tool description adds no additional parameter semantics. The baseline of 3 applies because the schema already 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 uses the specific verb 'Create' with the resource 'new Webhook.site token' and adds a clarifying parenthetical about it being a URL/email container. This clearly distinguishes it from sibling operations like update, delete, and get.
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?
There is no explicit guidance on when to use this tool versus alternatives, nor any mention of prerequisites, exclusions, or scenarios where another tool would be more appropriate. The verb 'Create' implies its purpose, but the context of when to choose it is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete all or filtered requests from a Webhook.site token.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Filter to delete requests matching this search query | |
| api_key | No | Optional Webhook.site API key (or use WEBHOOK_SITE_API_KEY env var) | |
| date_to | No | Filter to delete requests up to this date (e.g. 'now-7d' or 'yyyy-MM-dd HH:mm:ss') | |
| token_id | No | The Webhook.site token UUID (or use WEBHOOK_SITE_TOKEN_ID env var) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the destructive action ('Delete all or filtered requests') without disclosing irreversibility, authentication requirements, or potential side effects. With no annotations provided, the description carries the full burden of behavioral transparency, but it does not add the necessary caution or context for a deletion tool.
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 sentence with no filler words, and it is front-loaded with the primary action. Every word earns its place, making it highly concise and well-structured for a tool with a clear purpose.
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?
Despite the schema richness and presence of an output schema, the description is too sparse for a destructive tool with four optional parameters. It does not explain the implications of deleting all requests, the need for token_id, or how filtering works. The description is minimally adequate but leaves important operational context unstated.
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 input schema provides 100% description coverage for all four parameters, each with its own explanation. The description itself adds no parameter-specific semantics, but the baseline of 3 applies since the schema already documents the parameters in detail. The description does not repeat or contradict the 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 action (delete), the resource (requests), and the scope (from a Webhook.site token). It distinguishes itself from siblings like delete_token (which deletes the token itself) and list_requests (which lists rather than deletes). The verb and object are specific and unambiguous.
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?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description does not mention that the tool deletes all requests if no query is given, or how it relates to delete_token or list_requests. It is a single declarative sentence with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a Webhook.site token/URL completely.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | Optional Webhook.site API key (or use WEBHOOK_SITE_API_KEY env var) | |
| token_id | No | The Webhook.site token UUID (or use WEBHOOK_SITE_TOKEN_ID env var) |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states 'completely' hinting at destructive/irreversible deletion, but it does not specify whether associated requests are also deleted, authentication requirements, or any side effects. This is a significant gap for a destructive tool.
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, succinct sentence that is front-loaded with the action. It is appropriately concise for a simple delete tool, though it could include more detail without becoming verbose.
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?
Despite having an output schema and fully covered parameters, the description is too sparse for a destructive operation. It lacks essential behavioral context such as side effects, irreversibility, permissions, and what happens on success or failure. This makes it barely sufficient for an agent to safely use the 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?
The input schema provides 100% coverage for both parameters (api_key and token_id) with descriptions about being optional or using environment variables. The description adds no parameter-specific meaning, but since the schema already documents them thoroughly, the baseline of 3 applies.
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 uses the verb 'Delete' and identifies the resource as 'Webhook.site token/URL completely', making it clear that this tool removes a token/URL. This clearly distinguishes it from sibling tools like get_token, create_token, and update_token.
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 usage is for deleting a token/URL, but provides no explicit when-to-use or exclusion information. It does not mention related tools like delete_requests or prerequisites such as needing a token_id, so guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the latest raw request body sent to a Webhook.site token.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | Optional Webhook.site API key (or use WEBHOOK_SITE_API_KEY env var) | |
| token_id | No | The Webhook.site token UUID (or use WEBHOOK_SITE_TOKEN_ID env var) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must cover behavioral traits. It merely states that the tool gets the latest body, but does not mention error behavior when no requests exist, authentication requirements beyond the schema, or whether the operation is read-only. This lacks sufficient detail for a tool with no annotation support.
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, focused sentence with no redundant words or filler. It is front-loaded with the core action and resource, making it an efficient and appropriately sized description.
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?
The tool is simple with only two optional parameters and an output schema, so the description covers the core operation. It does not include guidance on when to use it relative to siblings, which is a minor gap, but overall the description, schema, and output schema provide enough context for correct invocation.
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 input schema descriptions are complete (100% coverage) for api_key and token_id, including environment variable fallbacks. The description adds no extra parameter semantics, but the baseline of 3 is appropriate because the schema already fully documents the parameters.
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 uses a specific verb ('Get') and a specific resource ('raw request body sent to a Webhook.site token'), clearly distinguishing this from sibling tools like list_requests by focusing on 'latest' and 'raw body'. It precisely states what the tool does with no ambiguity.
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?
No explicit guidance is provided on when to use this tool versus list_requests or other siblings. However, the phrase 'latest' and 'raw request body' implies a specific use case of retrieving a single most recent request, which gives some contextual cue.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details and configuration of a Webhook.site token.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | Optional Webhook.site API key (or use WEBHOOK_SITE_API_KEY env var) | |
| token_id | No | The Webhook.site token UUID (or use WEBHOOK_SITE_TOKEN_ID env var) |
| Name | Required | Description |
|---|---|---|
No output 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 of behavioral disclosure. It only says 'Get details and configuration' and does not mention authentication, side effects, error behavior, or confirm that it is a safe, read-only operation. It adds no behavioral context beyond what the tool's name suggests.
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, well-structured sentence with no filler. It starts with the verb 'Get,' then the resource and scope, maximizing clarity and efficiency.
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?
The tool is simple and the input schema is fully described, with an output schema present to define return values. However, the description lacks guidance on when to use this tool versus siblings and does not explicitly mention its read-only nature. Given the minimal scope, this is still fairly complete.
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 input schema fully describes both parameters (api_key and token_id) with 100% coverage, including their optionality and env var fallbacks. The description adds no further parameter context, so the baseline score of 3 applies.
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 action ('Get') and the resource ('a Webhook.site token'), specifying that it returns 'details and configuration.' This distinguishes it from sibling tools like create_token, update_token, and delete_token, which all have different verbs.
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 usage for retrieving token information but provides no explicit when-to-use guidance, alternatives, or exclusions. It relies on the name and sibling list to infer its read-only purpose, making it minimally viable but not explicitly instructive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List captured requests, emails, and DNSHooks sent to a token.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number to retrieve (default 1) | |
| query | No | Search query to filter requests | |
| api_key | No | Optional Webhook.site API key (or use WEBHOOK_SITE_API_KEY env var) | |
| date_to | No | Filter requests up to this date (format 'yyyy-MM-dd HH:mm:ss') | |
| sorting | No | Sorting order: 'newest' or 'oldest' (default 'newest') | newest |
| per_page | No | Number of requests to return per page (default 50, max 100) | |
| token_id | No | The Webhook.site token UUID (or use WEBHOOK_SITE_TOKEN_ID env var) | |
| date_from | No | Filter requests from this date (format 'yyyy-MM-dd HH:mm:ss') |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only states a simple listing action. It does not disclose pagination behavior, search/filtering effects, authentication requirements, or read-only nature beyond the implicit 'List'.
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?
A single, front-loaded sentence with zero redundant information. Every word contributes to the core purpose.
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?
The tool has 8 optional parameters, pagination, search, and date filters, yet the description is extremely terse. It doesn't address the diversity of captured items or how the scheduling/filtering works, leaving the agent without enough context to use the tool effectively.
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 baseline is 3. The description adds no parameter-specific meaning, but the schema already fully documents each parameter, so no additional compensation is needed.
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 uses a specific verb ('List') and identifies the resource ('captured requests, emails, and DNSHooks sent to a token'). This clearly distinguishes it from sibling tools like get_latest_request (single item) and get_token (token management).
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?
No guidance is provided on when to use this tool versus alternatives. It neither specifies the context (e.g., browsing history) nor mentions exclusions (e.g., use get_latest_request for a single request).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update settings of a Webhook.site token.
| Name | Required | Description | Default |
|---|---|---|---|
| cors | No | If true, adds CORS headers to responses | |
| alias | No | Sets a custom alias (regex: [a-zA-Z0-9-_]{3,32}) | |
| expiry | No | Seconds until the token auto-expires (max/default: 604800, i.e. 1 week) | |
| listen | No | Seconds to listen for response from "Set Response" endpoint (max: 10) | |
| actions | No | Enables or disables Custom Actions for the token | |
| api_key | No | Optional Webhook.site API key (or use WEBHOOK_SITE_API_KEY env var) | |
| timeout | No | Seconds to sleep before returning the response (max: 30) | |
| token_id | No | The Webhook.site token UUID (or use WEBHOOK_SITE_TOKEN_ID env var) | |
| request_limit | No | Limits request history stored (0 to 10000; default: 10000) | |
| default_status | No | The default HTTP response status returned to requests (200-599) | |
| default_content | No | The default response body content | |
| default_content_type | No | The default response Content-Type (e.g. 'text/html', 'application/json') |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states 'Update settings,' implying mutation, but does not disclose side effects, authentication needs, reversibility, or behavior on invalid input.
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 concise sentence with no redundant words. It is front-loaded and not verbose, though it lacks detail.
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 tool with 12 optional parameters and no annotations, the one-sentence description is insufficient. It does not explain update semantics, prerequisites, or how it fits with sibling operations, despite the output schema covering return values.
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 all 12 parameters. The description adds no parameter-specific information, meriting the baseline score of 3.
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 uses the specific verb 'Update' and identifies the resource as 'settings of a Webhook.site token.' It distinguishes from siblings like get_token and delete_token, but does not enumerate specific settings, making it slightly less precise.
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?
No guidance is provided regarding when to use this tool versus alternatives. It does not mention prerequisites such as an existing token or explain how it differs from create_token/delete_token.
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.
v0.1.0create_tokendelete_requestsdelete_tokenget_latest_requestget_tokenlist_requestsupdate_tokenEach tool targets a distinct resource and action: token lifecycle (get/create/update/delete) versus request inspection (list/latest/delete). There is no meaningful overlap between any pair of tools; get_latest_request is a specific convenience distinct from listing all requests.
All tool names follow a consistent verb_noun pattern with snake_case: get_token, create_token, update_token, delete_token, list_requests, get_latest_request, delete_requests. This makes the toolset predictable and easy to navigate.
The server has exactly 7 tools, which is well-scoped for a webhook testing and inspection service. Each tool covers an essential operation without redundancy or feature bloat.
The token CRUD lifecycle is fully covered, and request operations include listing, fetching the latest, and deleting. The only minor gap is the lack of a direct endpoint to fetch a specific request by ID, but list_requests likely provides enough detail for most workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Webhook capture bins for agents: get a URL, wait for webhooks, set replies, verify signatures.
Receive, inspect, replay and deliver webhooks — with signature verification and agent triggers.
Instant no-signup webhook & HTTP-request inspector for testing webhooks and agent tool-callbacks.
Anonymous webhook capture, inspection, waiting, and response configuration for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/js-cohn/Webhook.site-FastMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
