Webhooks da RD Station Marketing. Ações:
list: lista webhooks configurados.
create: cria um webhook (passe 'webhook' com url, event_type, entity_type…).
delete: remove um webhook (requer uuid).
[Flattened action: delete]
| Name | Required | Description | Default |
|---|---|---|---|
| uuid | No | ||
| account | No | ||
| webhook | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'remove um webhook' implying a destructive action, but annotations set destructiveHint to false. This is a contradiction. No further behavioral details are provided.
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 poorly structured, mixing general information about webhooks with a list of three actions, only one of which pertains to this tool. The flattened action note adds clutter. It is not concise and contains 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?
The description lacks details on return values, error conditions, or how to obtain the uuid. Given the lack of output schema and the complexity of the tool (3 parameters, nested objects), more context is needed for correct usage.
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 description specifies that uuid is required for delete, which adds some semantics, but the input schema shows all parameters optional and does not enforce a requirement. The webhook parameter is described for create, but for delete it is irrelevant. Schema coverage is 0%, so the description should compensate but does so inadequately.
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 includes a bullet for delete ('remove um webhook (requer uuid)') but also lists list and create actions, making the purpose less distinct. The tool's primary function is clear but diluted by extraneous information.
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 is provided on when to use this tool versus alternatives like rdstation_webhooks_list or rdstation_webhooks_create. The description does not mention context, prerequisites, or exclusions.
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.
The three rdstation_contacts_* tools and three rdstation_webhooks_* tools have identical descriptions listing the same set of actions, making them indistinguishable. An agent cannot determine which tool performs which action based on the descriptions alone.
Naming conventions are inconsistent: domain-specific tools use `rdstation_<noun>_<action>` (rdstation_contacts_get) but also `rdstation_<action>_<noun>` (rdstation_list_accounts), and some tools lack the domain prefix (authenticate, marketplace). The pattern varies across the set.
At 15 tools, the count is at the upper bound of reasonable scope. However, many tools are redundant (e.g., three tools for contacts actions) and could be consolidated, making the set feel heavier than necessary.
The RD Station domain covers contacts, webhooks, events, and accounts. However, contacts lack a delete action, and there is no tool to list contacts. The webhooks set is complete (create, list, delete) but missing an update. Minor gaps exist.