Webhook.site MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.3/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Webhook.site-FastMCP MCP server](https://glama.ai/mcp/servers/js-cohn/Webhook.site-FastMCP/badges/card.svg)](https://glama.ai/mcp/servers/js-cohn/Webhook.site-FastMCP)

Score Badge

Copy to your README.md:

[![Webhook.site-FastMCP MCP server](https://glama.ai/mcp/servers/js-cohn/Webhook.site-FastMCP/badges/score.svg)](https://glama.ai/mcp/servers/js-cohn/Webhook.site-FastMCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/js-cohn/Webhook.site-FastMCP'

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