Allows creating webhook bins for testing Stripe webhooks, replaying captured events to local servers, and mocking Stripe API endpoints (e.g., /v1/charges) with custom responses.
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., "@RequestBin MCP Server Create a webhook bin for testing my Stripe integration"
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.
Use RequestBin directly in Claude Code, Cursor, Windsurf, and any MCP-compatible AI coding agent.
Create webhook bins, inspect captured HTTP requests, replay them, and stand up mock API endpoints — all without leaving your editor.
npm install -g @requestbin/mcp-serverOr run directly with npx:
npx @requestbin/mcp-serverRelated MCP server: reqlog
Go to requestbin.net/api-keys
Create a new API key
API keys and MCP access are available on every plan, including FREE (5 keys per account). Per-feature limits (bin count, mock endpoint count, custom mock slug) still apply per plan — see requestbin.net/pricing.
Add to your project's .mcp.json or ~/.claude/settings.json:
{
"mcpServers": {
"requestbin": {
"command": "requestbin-mcp",
"env": {
"REQUESTBIN_API_KEY": "rb_your_key_here"
}
}
}
}Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"requestbin": {
"command": "requestbin-mcp",
"env": {
"REQUESTBIN_API_KEY": "rb_your_key_here"
}
}
}
}Add to Cursor Settings > MCP Servers:
{
"requestbin": {
"command": "requestbin-mcp",
"env": {
"REQUESTBIN_API_KEY": "rb_your_key_here"
}
}
}Add to ~/.windsurf/mcp_config.json:
{
"mcpServers": {
"requestbin": {
"command": "requestbin-mcp",
"env": {
"REQUESTBIN_API_KEY": "rb_your_key_here"
}
}
}
}Webhook bins & replay:
Tool | Description |
| List all your webhook bins with URLs and stats |
| Create a new webhook bin (returns URL for webhook endpoint) |
| Get bin details including recent interactions |
| Delete a webhook bin |
| List captured HTTP requests for a bin (method, headers, body) |
| Send an HTTP request to any URL (server-side replay) |
| Check the status of a replay job |
| List available servers for bin creation |
Mock APIs (*.rbmock.dev):
Tool | Description |
| List your mock endpoints with slug, URL, and rule count |
| Create a mock endpoint (returns live |
| Append a routing rule (match method/path → status + headers + body) |
| Publish the current rule set so the live mock server picks it up |
| List recent requests that hit a mock endpoint — verify your integration is actually calling the mock URL |
Here is what a typical conversation looks like with an AI agent that has the RequestBin MCP server configured:
You: "Create a webhook bin for testing my Stripe integration"
The agent will:
Call list_servers to find available servers
Call create_bin with name "Stripe Webhooks"
Return the bin URL to configure in your Stripe Dashboard
You: "Show me the last 5 requests to my Stripe webhook bin"
The agent will:
Call list_bins to find your bins
Call list_interactions with the bin ID and limit of 5
Display the HTTP method, path, headers, and body of each captured request
You: "Replay the last webhook event to my local server at localhost:3000/webhooks"
The agent will:
Call list_interactions to find the most recent request
Call replay_request with the same method, headers, and body targeting http://localhost:3000/webhooks
Call get_replay_status to confirm delivery
You: "Stand up a mock Stripe API that returns 200 for POST /v1/charges and 402 for POST /v1/charges/decline"
The agent will:
Call create_mock_endpoint with name "Stripe mock" — gets back a live URL like https://abc12.rbmock.dev
Call add_mock_rule twice (one per path) with the matching status codes and JSON bodies
Call deploy_mock to publish — the URL is now ready to point your integration at
Variable | Required | Default | Description |
| Yes | -- | Your API key from requestbin.net/api-keys |
| No |
| Custom API base URL (for self-hosted instances) |
| No |
| Domain that hosts mock endpoints (override for self-hosted) |
Node.js >= 18
A RequestBin account (FREE tier works — API/MCP is open to every plan)
npm install
npm run dev # runs with tsx (hot reload)
npm run build # compile TypeScript to dist/MIT
Append a routing rule to a mock endpoint. Rules are matched in priority order; the first match wins. After adding rules, call deploy_mock to publish them.
| Name | Required | Description | Default |
|---|---|---|---|
| endpointId | Yes | The mock endpoint ID (from list_mock_endpoints / create_mock_endpoint) | |
| method | Yes | HTTP method to match. Use "*" to match any method. | |
| path | Yes | Path to match (e.g. "/users", "/api/v1/*"). Use "*" to match any path. | |
| statusCode | Yes | HTTP status code to return (100–599) | |
| body | No | Response body (string; for JSON, pass a serialized JSON string) | |
| headers | No | Response headers as a flat object (e.g. {"Content-Type": "application/json"}) | |
| priority | No | Higher priority rules are evaluated first (default 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description discloses priority ordering and need to deploy, but lacks details on idempotency, error behavior, or whether addition replaces existing rules.
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?
Two sentences, front-loaded with purpose, no redundant information.
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 or output schema, description covers core workflow (add then deploy) and ordering, but omits return value or error handling.
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 covers 100% of parameters, so baseline is 3; description adds context about priority ordering but does not enhance understanding of other parameters beyond 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?
Description specifies verb 'Append' and resource 'routing rule to a mock endpoint', clearly distinguishing from sibling tools like create_mock_endpoint and deploy_mock.
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?
Provides explicit post-usage instruction ('After adding rules, call deploy_mock to publish them') and explains matching priority, though does not contrast with alternatives for adding rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new webhook bin to capture HTTP requests. Returns the bin URL you can use as a webhook endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name for the bin (e.g. "Stripe Webhooks", "GitHub Events") | |
| serverId | Yes | Server ID to create the bin on. Use list_servers to find available servers. | |
| note | No | Optional note/description for the bin |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral context. It discloses that the tool creates a bin and returns a URL, but does not mention persistence, rate limits, or any side effects. This is adequate but minimal.
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 consists of two clear, front-loaded sentences with no unnecessary words. Every sentence adds value, making it highly concise 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 the tool's simplicity and lack of output schema, the description is reasonably complete. It explains the core action and return value. Minor gaps exist (e.g., whether the bin starts capturing immediately), but these are not critical for a creation 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?
All three parameters are fully described in the input schema (100% coverage). The description adds no additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
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 explicitly states the tool creates a new webhook bin to capture HTTP requests and returns the bin URL. This is a specific verb+resource combination that clearly distinguishes it from sibling tools like list_bins or delete_bin.
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 implied usage context (to capture HTTP requests) but does not explicitly state when to use this tool versus alternatives like create_mock_endpoint. No exclusions or when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a mock API endpoint. Returns a live URL ({slug}.rbmock.dev) that responds to HTTP requests with rules you configure. A starter rule (any-method any-path → 200 JSON) is added automatically. Custom slugs require PRO/TEAM; otherwise an auto-slug is generated.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Display name for the endpoint (e.g. "Stripe API mock", "Auth fixture") | |
| slug | No | Custom subdomain slug (PRO/TEAM only). Leave empty for an auto-generated slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: auto-creation of a starter rule, live URL format, and PRO/TEAM requirement for custom slugs. No annotations exist, so the description carries the burden well.
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?
Three front-loaded sentences, each concise and informative. No wasted words; structure flows from action to result to special case.
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?
Adequately explains purpose, result (URL), and behavior (starter rule, slug rules). Could mention return format more explicitly, but overall sufficient for a two-parameter 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 coverage is 100% with clear param descriptions. The description adds valuable context: slug can be left empty for auto-generation, and custom slugs require higher subscription tier.
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?
Clearly states 'Create a mock API endpoint' and distinguishes itself from siblings like add_mock_rule by describing the core function: producing a live URL with configurable rules.
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?
Indicates when to use (creating a mock endpoint) and provides context on slug requirements (PRO/TEAM for custom). However, no explicit guidance on when not to use or alternatives among siblings like deploy_mock.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a webhook bin (soft delete)
| Name | Required | Description | Default |
|---|---|---|---|
| binId | Yes | The bin ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description mentions 'soft delete' but does not explain what that entails (e.g., recoverability, visibility after deletion), missing important behavioral details for a destructive operation.
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?
Single sentence, front-loaded with the key information, no superfluous content.
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 single-parameter delete tool with no output schema, the description is adequate in stating the basic purpose but lacks behavioral details (soft delete semantics) that would make it fully informative.
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 coverage is 100% with a parameter description for binId; the tool description adds no additional meaning beyond the schema for the parameter, so a baseline 3 is appropriate.
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 verb 'Delete' and the resource 'webhook bin', and specifies it's a 'soft delete', distinguishing it from potential hard delete tools among siblings.
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 on when to use this tool vs alternatives, no prerequisites or context about soft delete implications, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Publish the current rule set of a mock endpoint to the live mock server. Bumps the configVersion and invalidates edge caches so new requests see the latest rules.
| Name | Required | Description | Default |
|---|---|---|---|
| endpointId | Yes | The mock endpoint ID to deploy |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behavioral impacts: bumping configVersion and invalidating edge caches, which are important for understanding side effects. It does not cover permissions or reversibility, but given the simple action, it provides adequate 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 two sentences, front-loaded with the action, and every part adds value. No superfluous words or repetition.
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?
With one parameter, no output schema, and no annotations, the description covers the operation, its purpose, and side effects. It is complete enough for an agent to choose and invoke the tool correctly, though it lacks return value details.
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 only parameter, endpointId, has a schema description ('The mock endpoint ID to deploy') that already conveys its meaning. The tool description adds no additional semantics beyond what the schema provides. With 100% schema coverage, a baseline of 3 is appropriate.
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 it publishes a mock endpoint's rule set to the live server, specifying the action ('Publish'), the resource ('current rule set of a mock endpoint'), and the effect ('bumps the configVersion and invalidates edge caches'). Among siblings like add_mock_rule and create_mock_endpoint, it uniquely identifies the deployment action.
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 when you need to make rule changes live, but does not explicitly state when not to use it or contrast with siblings. However, the context (siblings include add_mock_rule, list_mock_endpoints) makes the purpose clear enough for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific bin including recent interactions
| Name | Required | Description | Default |
|---|---|---|---|
| binId | Yes | The bin ID (UUID format) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only mentions 'get details' without clarifying it's a read-only operation or disclosing any side effects, permissions, or data limits.
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 redundant information, efficiently conveying the tool's 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?
For a simple get-by-ID tool with no output schema, the description is adequate but lacks details on returned fields, error handling, or what 'recent' means.
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% for the single parameter, so the description adds no additional meaning beyond what is already in 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 it retrieves details of a specific bin, including recent interactions, distinguishing it from siblings like list_bins.
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 on when to use this tool over alternatives; usage is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of a replay job
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | The replay job ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the operation is read-only, possible side effects, or what statuses can be returned. The description carries the full burden but fails to elaborate.
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?
Single sentence directly stating the tool's purpose with no extraneous content. Efficient 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?
With no output schema, the description should ideally explain what the response contains (e.g., status fields). It does not, leaving a gap in completeness. However, the tool is simple with one parameter, so a 3 is reasonable.
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 coverage is 100% (the only parameter 'jobId' is described in the schema). The description adds no additional meaning beyond 'The replay job ID', so baseline 3 is appropriate.
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 ('Check') and resource ('replay job'), clearly distinguishing it from sibling tools like 'replay_request' which initiates a replay.
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 on when to use this tool, prerequisites, or when to avoid it. The description is minimal and does not provide usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all your webhook bins with their URLs and stats
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It indicates a read operation but doesn't disclose aspects like pagination, rate limits, or scope of 'all' (e.g., across workspaces). Minimal but adequate.
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?
Single sentence, highly concise, no wasted words. Directly states purpose and output.
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 list tool without output schema, the description fully covers purpose and expected return ('URLs and stats'). No additional details needed.
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?
No parameters exist, schema coverage is 100%. Baseline score of 4 applies per guidelines since description adds no parameter info, which is acceptable.
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?
Description has a specific verb 'List', resource 'webhook bins', and specifies output 'URLs and stats'. Clearly distinguishes from sibling tools like list_interactions or list_mock_endpoints.
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 on when to use this tool vs alternatives (e.g., when to use list_interactions). The description implies using for bins but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List captured HTTP requests (interactions) for a bin
| Name | Required | Description | Default |
|---|---|---|---|
| binId | Yes | The bin ID | |
| limit | No | Number of interactions to return (default 10, max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It fails to mention important aspects such as pagination, ordering (e.g., most recent first), error handling if the bin ID is invalid, or whether the operation affects the bin. The description adds minimal behavioral context beyond what the schema indicates.
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 that front-loads the primary action and resource. It contains no unnecessary words or repetitions, making it easy for an agent to parse quickly.
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 low complexity (2 parameters, no output schema, no nested objects), the description is mostly adequate but insufficient in context. It does not specify the order of returned interactions (e.g., chronological), list any constraints, or mention what the response format looks like. This omission may leave an agent uncertain about the output.
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%, with clear descriptions for both parameters: binId ('The bin ID') and limit ('Number of interactions to return (default 10, max 50)'). The tool description does not add any additional meaning or context beyond the schema, so it meets the baseline expectation.
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 verb 'list' and the resource 'captured HTTP requests (interactions)' with the context 'for a bin'. It effectively distinguishes itself from sibling tools like list_bins (which lists bins) and list_mock_captures (which returns captured mock endpoint requests).
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 that this tool is used to list interactions for a specific bin, but it provides no explicit guidance on when to use it versus alternatives, when not to use it, or any prerequisites. The context is clear enough for basic use, but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent captured requests that hit a mock endpoint. Use this to verify your integration is actually calling the mock URL — shows method, path, status, and time for each capture. Returns up to 50 by default.
| Name | Required | Description | Default |
|---|---|---|---|
| endpointId | Yes | The mock endpoint ID (from list_mock_endpoints) | |
| limit | No | Max captures to return (1-200, default 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses read-only nature, default limit of 50, and fields returned. Lacks explicit statement about idempotency or side-effects, but adequately covers key aspects.
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?
Two sentences, no fluff, front-loaded with purpose and usage. Every sentence adds meaningful information.
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?
Without output schema, the description explains return fields (method, path, status, time) and default limit. Does not cover error handling or edge cases, but sufficient for a list 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 coverage is 100%, and description adds value by noting 'endpointId (from list_mock_endpoints)' for sourcing the ID and 'Returns up to 50 by default' for the limit parameter, complementing schema-defined bounds.
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 lists recent captured requests for a mock endpoint, specifies the information shown (method, path, status, time), and distinguishes from general interaction lists by focusing on mock endpoints.
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?
Explicitly states when to use: 'Use this to verify your integration is actually calling the mock URL.' Does not mention alternatives or exclusions, but the context is clear for a simple list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your mock API endpoints (custom HTTP responses at {slug}.rbmock.dev). Useful for finding endpoint IDs and current rule counts.
| 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 states the tool lists endpoints and returns IDs and rule counts, implying a read-only operation. However, it does not explicitly confirm non-destructiveness, mention pagination, or disclose any rate limits or side effects.
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 two sentences, front-loaded with the core function and URL pattern, followed by a specific use case. Every word adds value with no redundancy.
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 simple list tool with no parameters, no output schema, and no annotations, the description covers purpose, output topics (IDs and rule counts), and a use case. It could be slightly enhanced by noting the operation is read-only or scoped to the user's account, but it is largely 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 has zero parameters and 100% schema coverage (no parameters to describe). According to guidelines, 0 parameters yields a baseline score of 4, and the description adds no parameter information, which is acceptable.
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 lists mock API endpoints with a specific URL pattern ({slug}.rbmock.dev) and notes it returns endpoint IDs and rule counts. This distinguishes it from sibling tools like list_bins and list_mock_captures, which list different resources.
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 says 'Useful for finding endpoint IDs and current rule counts,' which implies when to use it, but it does not explicitly exclude alternatives or provide when-not-to-use guidance. The sibling tools (e.g., list_mock_captures) are not compared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available servers (needed for creating bins). Returns server IDs you can use with create_bin.
| 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 must disclose behavioral traits. It only states it lists servers and returns IDs, but omits details like whether it is a read operation, any authentication requirements, or rate limits. The description does not add much beyond the name.
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 that immediately conveys the tool's purpose and output usage. No wasted words.
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 simplicity (no parameters, no output schema), the description is complete. It explains what the tool does, why it's needed, and how to use the result.
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 has zero parameters (100% coverage), so the description does not need to add parameter details. Baseline score of 4 is appropriate as there is no missing information.
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 lists servers, explains its purpose ('needed for creating bins'), and specifies what it returns ('server IDs you can use with create_bin'). It distinguishes itself from siblings like create_bin and list_bins.
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 indicates when to use this tool: before creating bins, as the returned server IDs are needed for create_bin. It implies a sequential dependency but does not explicitly mention when not to use it or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send an HTTP request to any URL (replay/test webhook delivery). The request is executed server-side.
| Name | Required | Description | Default |
|---|---|---|---|
| method | Yes | HTTP method | |
| url | Yes | Target URL to send the request to | |
| headers | No | HTTP headers to include | |
| body | No | Request body (for POST/PUT/PATCH) | |
| bodyMode | No | Body content type | none |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It mentions server-side execution but omits details on authentication, rate limits, response handling, or security implications of sending requests to arbitrary URLs.
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?
Two sentences that are concise and front-loaded with the core purpose. Every sentence adds value without redundancy.
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 that sends arbitrary HTTP requests, the description lacks critical contextual details such as return value, error behavior, and security considerations. No output schema exists to compensate.
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 coverage is 100%, so baseline is 3. The description adds no additional meaning beyond what the schema already provides for 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 clearly states the tool sends an HTTP request to any URL, specifically for replaying/testing webhook delivery. This is distinct from sibling tools that handle bin management or interaction listing.
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 gives context ('replay/test webhook delivery') but does not explicitly guide when to use this tool vs alternatives, nor does it provide exclusions or alternative tool names.
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.3.0add_mock_rulecreate_bincreate_mock_endpointdelete_bindeploy_mockget_binget_replay_statuslist_binslist_interactionslist_mock_captureslist_mock_endpointslist_serversreplay_requestTools clearly separate bin and mock endpoint domains, but some overlap exists between list_interactions and list_mock_captures; descriptions help distinguish them.
All tool names follow a consistent verb_noun pattern with snake_case, e.g., create_bin, list_mock_endpoints, replay_request.
13 tools is well-scoped for managing webhook bins and mock endpoints, covering creation, listing, rules, and replay without being excessive.
Core workflows are present, but notable gaps exist: no delete_mock_endpoint, no update/remove rule operations, and mock endpoint details are limited to listing.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Instant no-signup webhook & HTTP-request inspector for testing webhooks and agent tool-callbacks.
Debug webhooks from your AI agent: inspect and replay captured webhooks on localhost.
A webhook inbox for agents: one call returns a live URL. Mock, verify, inspect and replay.
Receive, inspect, replay and deliver webhooks — with signature verification and agent triggers.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/requestbin/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
