Skip to main content
Glama

Add form webhook

add_form_webhook
Idempotent

Add a notification webhook URL to a form.

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": {
      "id": "<id>",
      "url": "<url>"
    },
    "name": "add_form_webhook"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesForm ID or form key
urlYesWebhook URL (Slack, Discord, or generic HTTP endpoint)

Output Schema

NameRequiredDescriptionDefault
dataYesResponse body returned by the SubmitraX API

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / id / description
      Added value: +"Form ID or form key"
    • addedInput schema / properties / url / description
      Added value: +"Webhook URL (Slack, Discord, or generic HTTP endpoint)"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": false,
      +  "properties": {
      +    "data": {
      +      "description": "Response body returned by the SubmitraX API"
      +    }
      +  },
      +  "required": [
      +    "data"
      +  ],
      +  "type": "object"
      +}
  2. First observed

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the agent knows this is a safe, repeatable external-facing write. The description adds only the 'notification' nature of the webhook, saying nothing about duplicate handling, permissions, or what the call returns.

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?

A single front-loaded sentence with no wasted words. It is efficient, but its brevity borders on under-specification for a mutation tool rather than being optimally informative.

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

Completeness3/5

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

With an output schema present and full parameter coverage, the description need not explain return values. Still, for a non-read-only, open-world mutation it omits any mention of prerequisites or duplicate-URL behavior, leaving the definition only minimally 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?

Schema description coverage is 100%, so the schema already documents both `id` (form ID or key) and `url` (Slack/Discord/generic endpoint). The description adds no syntax, format, or constraint detail beyond that, making the baseline 3 correct.

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 states a specific verb ('Add') and resource ('notification webhook URL') applied to a clear target ('to a form'). It implicitly differentiates from siblings like list_form_webhooks and delete_form_webhook through the verb, though it never names them explicitly.

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 guidance on when to use this tool versus list_form_webhooks or delete_form_webhook, nor any prerequisite, auth, or rate-limit context. The word 'notification' hints at the purpose but usage remains entirely inferred.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources