Proof Holdings

create_webhook_endpoint

Add a webhook endpoint. An event reaches every active endpoint whose scope includes the event's sub-account and whose events match; an account-level event reaches "all"-scope endpoints only. An account still delivering to the single webhook URL in its settings is moved onto endpoints by this call (that URL becomes an "all"-scope endpoint with the same secret and events). The response carries the endpoint's signing secret — this and rotate_webhook_endpoint_secret are the only times it is returned, so store it now. Deliveries carry an HMAC-SHA256 X-Proof-Signature over "." made with it.

ACCESS: needs a Proof account. Authenticate this client (Claude Code: /mcp → Authenticate), then call this tool again. start_login does NOT open this tool.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>",
      "scope": "<scope>"
    },
    "name": "create_webhook_endpoint"
  }
}

Input Schema

Name	Required	Description
`url`	Yes	HTTPS URL deliveries are sent to, at most 2000 characters. Private, loopback and link-local addresses are refused.
`scope`	Yes	"all" serves every sub-account, present and future, plus account-level events; "selected" serves only the sub-accounts in profile_ids
`events`	No	Subscription patterns (at most 32): an exact event type, a family wildcard such as "proof.", or "". An empty list means every event.
`status`	No	A disabled endpoint receives nothing
`description`	No	Your own label for the endpoint, at most 200 characters; null clears it
`profile_ids`	No	Sub-account ids, 24 hex characters each, at most 100. At least one when scope is "selected"; none when scope is "all".

Output Schema

Name	Required	Description
`id`	No	MongoDB ObjectId
`url`	No	HTTPS URL deliveries are POSTed to, at most 2000 characters. Private, loopback and link-local addresses are refused.
`scope`	No	`all` — every sub-account, present and future, plus account-level events. `selected` — only the sub-accounts in `profile_ids`; account-level events never reach it.
`events`	No
`legacy`	No	The endpoint converted from the account's single webhook URL — the one the deprecated `/me/settings` webhook block reads and writes.
`secret`	No	The signing secret — returned only in this response. Store it now.
`status`	No	A `disabled` endpoint receives nothing; its history and secret are kept.
`created_at`	No
`secret_set`	No	Whether the endpoint has a signing secret (always true).
`updated_at`	No
`description`	No
`profile_ids`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 2, 2026

TDQS

A4.7/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, it discloses important behavior: how events route to endpoints by scope and event matching, how existing single-URL webhook settings are migrated, that the response returns the signing secret only once, and how deliveries are signed with HMAC-SHA256. These are operationally critical details an agent would not know from readOnlyHint/destructiveHint alone.

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?

It is front-loaded with the core action and then presents only high-value behavioral details: routing, migration, secret handling, and authentication. Despite being longer than average, every sentence carries operational information relevant to correct invocation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The output schema exists, so return shape need not be fully described, but the description still highlights the critical return value: the one-time signing secret. It also covers authentication requirements, routing semantics, migration behavior, and security details, making it complete for this complex creation tool.

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?

Schema coverage is 100%, so the individual parameters are already well documented. The description adds cross-parameter meaning by explaining scope behavior, event matching, account-level event routing, and the migration effect of creating an endpoint, though it does not elaborate each parameter beyond 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 opens with a specific verb and resource: "Add a webhook endpoint." It also distinguishes this create operation from sibling update/rotate/list/delete webhook tools by explaining endpoint creation, scope matching, and one-time secret return.

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?

It clearly states the access prerequisite and that the client must authenticate then call the tool again. It also warns that the signing secret is only returned here and by rotate_webhook_endpoint_secret, but it does not explicitly contrast when to use this versus update_webhook_endpoint or list_webhook_endpoints.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Proof Holdings tools Inspect

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.