A
licenseA
qualityC
maintenanceProvides timing-safe, replay-resistant webhook signature verification for Stripe, GitHub, Slack, Shopify, and Twilio, returning valid/invalid with precise failure reasons.
1
MIT
Agent Verifier
by guru.packet
Server Details
Test and debug your AI agent's Web Bot Auth (RFC 9421) signature: is it valid, and what to fix?
Ownership verified
- Status
- Healthy
- Uptime
- 99.9% over 21 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A4.4/5.0
Scored across 1 tool
Disambiguation5/5
There is only one tool, so there is no possibility of confusing it with another. Its purpose (self-diagnosing how the current request looks from the outside, including Web Bot Auth signature verification) is unambiguous.
Naming Consistency5/5
A single snake_case name, self_check_web_bot_auth, that clearly encodes subject (web bot auth) and action (self check). With one tool there is no convention to break.
Tool Count4/5
One tool is thin against the 3-15 heuristic, but the server's scope is a single diagnostic operation, so a solo tool is genuinely well-matched rather than an oversight. It is not a trivial stub; it returns verification status, key directory facts, faults, and address data.
Completeness4/5
For its stated narrow purpose the tool covers the full diagnostic loop: it works signed or unsigned and reports verification result, directory contents, fault text, remediation sentence, and caller-address facts. No obvious dead ends, though there are no companion operations (e.g. re-checking after a config change or inspecting a different request).
Available Tools
1 toolself_check_web_bot_authCheck my own Web Bot Auth setupARead-onlyIdempotentInspect
Reports how the request carrying this call looks from the outside: whether its Web Bot Auth (RFC 9421) signature verified, what the key directory it named publishes, the exact fault if there is one and the sentence saying what to change, plus plain facts about the address it arrived from. Sign the call the way you sign requests to anyone else. Free, anonymous, no account. Takes no arguments: an unsigned call still gets an answer about its address.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| id | No | Identifier for this verdict, safe to quote in a support request. |
| ip | No | Plain facts about your own address: network, operator, reputation of the address itself. |
| geo | No | Country, region, city and timezone of your address. |
| meta | No | Envelope: API version, how long the answer took, and the sources that contributed. |
| mode | No | You called this endpoint yourself, so the answer describes your own request. |
| signals | No | |
| success | No | Always true on a 200. Errors carry success:false and an error object. |
| identity | No | Who you were established to be, and on what evidence. Empty of judgement: the outcome of checking a signature you sent against a directory you published. |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, but the description adds real context: it is free, anonymous, requires no account, and produces a useful answer even when unsigned. It does not cover rate limits or whether the signature/address is retained, but the safety and auth profile is well disclosed.
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?
Front-loads the purpose in the first clause and then enumerates what is returned and how to invoke it. The result enumeration is dense and slightly redundant given an output schema exists, but every sentence carries information and none is filler.
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?
For a zero-argument diagnostic whose output schema exists, the description covers invocation, auth expectations, and the shape of the answer. Re-listing return fields is mildly redundant with the output schema, but nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so the baseline is 4; the description reinforces this by stating 'Takes no arguments' and explaining that an unsigned call is still valid. Nothing further is needed for an empty 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?
Names a precise verb and resource: it reports how the calling request looks from outside, specifically whether its RFC 9421 Web Bot Auth signature verified and what the named key directory publishes. An agent can tell exactly what this tool does without opening the schema, and no sibling tools exist to confuse it with.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States the invocation context explicitly ('Sign the call the way you sign requests to anyone else') and clarifies that an unsigned call still returns address information, so an agent knows it can call this both with and without a signature. No exclusions or alternatives are needed since there are no sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
self_check_web_bot_auth6 fields changed- changed
Output schema / properties / identity / properties / method / descriptionPrevious value: -"How the name was established: `signature` when your own signature verified, `range` when your address sat in a list its operator publishes."New value: +"How the name was established: signature when your own signature verified, ip-range when your address sat in a list its operator publishes." - changed
Output schema / properties / identity / properties / trusted / descriptionPrevious value: -"Whether the established name is one this verifier holds a trust anchor for. A verified signature from a domain nobody knows is a verified signature from a domain nobody knows."New value: +"Whether the established name is one this verifier holds a trust anchor for. A verified signature from an unknown domain still says who sent the request, and false here says that nothing more is known about that domain." - changed
Output schema / properties / meta / descriptionPrevious value: -"Envelope: API version, how long the verdict took, which axes contributed."New value: +"Envelope: API version, how long the answer took, and the sources that contributed." - changed
Output schema / properties / meta / properties / apiVersion / descriptionPrevious value: -"Version of this API. `v1` today."New value: +"Version of this API, such as v1." - changed
Output schema / properties / meta / properties / axes / descriptionPrevious value: -"Which sources contributed to this answer. An axis absent here contributed nothing, which is why a field can be missing without anything being wrong."New value: +"Sources that contributed to this answer, such as ip, knownBot and webBotAuth. A field can be missing without anything being wrong: its source did not contribute." - changed
Output schema / properties / signals / properties / agent / properties / knownBot / descriptionPrevious value: -"The second, independent check, and the one that has nothing to do with your signature: some operators publish the address ranges their crawlers use, and those lists are refreshed regularly. matched means the address this request came from is inside such a published range. none is the ordinary answer and is not a fault: it means no operator publishes a list containing this address, which is true of every address that is not a large crawler, and true of most agents."New value: +"A second check, independent of the signature. Some operators publish the address ranges their crawlers use, and those lists are refreshed regularly. matched means the address this request came from is inside such a range. none is the usual answer and not a fault: no operator publishes a list containing this address, which holds for most agents and for every address that is not a large crawler."
1 tool update
- Changed
self_check_web_bot_auth1 field changed- changed
Output schema / properties / signals / properties / agent / properties / knownBot / descriptionPrevious value: -"The second, independent check, and the one that has nothing to do with your signature: some operators publish the address ranges their crawlers use, and those lists are read here nightly. matched means the address this request came from is inside such a published range. none is the ordinary answer and is not a fault: it means no operator publishes a list containing this address, which is true of every address that is not a large crawler, and true of most agents."New value: +"The second, independent check, and the one that has nothing to do with your signature: some operators publish the address ranges their crawlers use, and those lists are refreshed regularly. matched means the address this request came from is inside such a published range. none is the ordinary answer and is not a fault: it means no operator publishes a list containing this address, which is true of every address that is not a large crawler, and true of most agents."
1 tool update
- First observed
self_check_web_bot_auth
Related MCP Connectors
Generates deterministic webhook HMAC-SHA256 fixtures and optionally verifies a supplied signature...
Debug webhooks from your AI agent: inspect and replay captured webhooks on localhost.
Webhook, email, WebSocket and tunnel testing for AI agents: capture, wait, verify, replay.
Issue signed receipts for AI agent actions; verify any receipt offline - free, no account.
Related MCP Servers
- FlicenseNot gradedqualityBmaintenanceEnables verifying event-driven webhook signatures and providing HMAC replay protection for AI agents and MCP clients.8-
- AlicenseAqualityBmaintenanceGive AI agents cryptographically signed proof of web observations: Ed25519-signed proof packets (HTTP status, page title, body SHA-256, DNS, TLS) for any public URL.1MIT
- AlicenseAqualityDmaintenanceWebhook management and testing tools for AI agents. Provides tools for sending, validating, generating, and debugging webhooks.511 npmMIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.