Skip to main content
Glama
fivetran

Fivetran MCP Server

Official
by fivetran

webhooks_read

Read-only

Read Fivetran webhook configurations: list all webhooks or get details for a specific webhook. Pass the endpoint name to choose the operation.

Instructions

Read operations on Fivetran webhooks (2 endpoints: list_all_webhooks, webhook_details). Pass the endpoint name in name. Call list_endpoints(category='webhooks') for the full list.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyNoRequest body — dict or JSON string. Required for POST/PATCH endpoints.
nameYesEndpoint name within this resource:action group (from list_endpoints).
queryNoQuery-string parameters.
path_paramsNoValues for path placeholders like {connectionId}, {groupId}.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.3.0

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds the dispatch mechanism (endpoint name passed via `name`) but says nothing about return shape, pagination, or per-endpoint caveats, so it clears the lowered bar without excelling.

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?

Two tight sentences with the resource and endpoint count front-loaded, followed immediately by the usage rule and discovery pointer. No 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 dispatcher with full schema coverage and safety annotations, plus a pointer to list_endpoints for discovery, the description is nearly sufficient. The absence of any per-endpoint behavior note (e.g., path placeholder needs for webhook_details) is a minor gap given no output schema exists.

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 `body`, `name`, `query`, and `path_params` are already documented in the schema. The description clarifies how `name` is populated (endpoint names from this group) but adds no syntax or format detail beyond that, matching the baseline 3 for schema-driven params.

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 names a specific verb and resource ('Read operations on Fivetran webhooks') and enumerates the two concrete endpoints it fronts (list_all_webhooks, webhook_details). An agent can immediately distinguish it from siblings like users_read, groups_read, or metadata_read.

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 tells the agent the calling protocol ('Pass the endpoint name in `name`') and routes to a concrete alternative for discovery ('Call list_endpoints(category=\'webhooks\') for the full list'). It gives clear context for use but does not state any when-not conditions.

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