test_webhookSend a signed test event containing no participant or study data. This makes an outbound request to the registered URL.
| Name | Required | Description | Default |
|---|---|---|---|
| webhook_id | Yes | ||
| organization_id | No | Platform admins only: select an organization for this operation. Required when changing another organization’s study or using its wallet. |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes | Signed test delivery result. |
Changes observed during successful MCP inspections.
Input schema / properties / organization_idAdded value: +{
+ "description": "Platform admins only: select an organization for this operation. Required when changing another organization’s study or using its wallet.",
+ "maxLength": 128,
+ "minLength": 1,
+ "type": "string"
+}Input schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / webhook_id / patternAdded value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"Output schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Output schema / properties / result / additionalPropertiesPrevious value: -trueNew value: +{}Output schema / properties / result / properties / status_code / anyOfPrevious value: -[
- {
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maximum": 9007199254740991,
+ "minimum": -9007199254740991,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations covering the safety profile (openWorldHint=true, readOnlyHint=false, idempotentHint=false), the description adds real value by disclosing that the emitted event is signed and carries no participant or study data, and that it triggers an outbound request to the registered URL. It stops short of noting side effects like delivery records being created or rate limits, but the added context is meaningful.
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 tightly written sentences with zero filler, and the most consequential fact — that a real outbound request is made — is placed prominently.
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?
An output schema exists, so return values need no explanation, and the annotations already declare the open-world, non-idempotent nature. The description covers payload contents and the outbound call, leaving only minor gaps such as permission requirements for the webhook owner.
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 only 50%: organization_id is documented in the schema, but webhook_id has no description at all. The description mentions no parameters, so it does not compensate for the coverage gap on the required identifier.
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 states a specific verb and resource ('Send a signed test event') and clarifies the scope of the payload ('containing no participant or study data'), which is more than a restatement of the name. It does not explicitly contrast with any sibling, but no sibling overlaps with this action, so differentiation is largely unnecessary.
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?
Usage is implied (test a registered webhook) but never stated as when-to-use guidance, and there is no mention of when not to use it or of alternatives such as list_webhook_deliveries for inspecting past deliveries. Adequate but with clear gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.