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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds that only one endpoint exists, useful scoping context, but says nothing about auth, rate limits, or response shape.

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 sentences, fully front-loaded: purpose first, discovery mechanism second. No filler.

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?

For a single-endpoint read tool with no output schema and annotations covering the safety profile, this is close to complete. The main missing piece is any hint of what get_account_info returns, though readOnlyHint lets the agent infer safe read semantics.

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 coverage is 100%, so baseline is 3. The description reinforces that `name` carries the endpoint identifier and points to list_endpoints as the source, but adds no syntax beyond what the schema already documents.

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?

States a specific verb and resource ('Read operations on Fivetran account') and names the exact endpoint covered (get_account_info). Distinguishes itself from siblings like connections_read or users_read by scoping to the account group.

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?

Tells the agent how to discover the full operation list via list_endpoints(category='account') and that the endpoint name goes in `name`. Doesn't explicitly state exclusions or when to prefer a different resource group, but the endpoint enumeration makes usage clear.

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

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 covered. The description adds the dispatcher structure (12 endpoints, required name) which is useful context, but nothing about return shape, pagination, or auth. With annotations carrying the behavioral load, a 3 is appropriate.

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 tight sentences, front-loaded with the purpose and endpoint inventory before the mechanics. The list compresses well, though the truncated '+ 4 more' enumeration is slightly awkward for an agent trying to see full coverage.

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?

For a multi-endpoint dispatcher with no output schema, the description supplies the essential discovery workflow (list_endpoints) and how to invoke sub-endpoints. Return values are necessarily defined by each endpoint rather than this wrapper, so the omission is acceptable, leaving only minor gaps.

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 100%, so the schema already documents name, body, query, and path_params. The description's guidance to pass the endpoint name largely restates what the schema's `name` field already says ('from list_endpoints'), adding only marginal value. Baseline 3 applies.

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?

States a specific verb (read operations) and resource (Fivetran connections) and enumerates the sub-endpoints covered, making the dispatcher nature unmistakable. An agent can immediately tell this group handles connections reads versus the other resource groups in the sibling list.

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?

Explicitly tells the agent to pass the endpoint name in `name` and to call list_endpoints(category='connections') to discover the full set, which is a clear usage workflow. It lacks any when-not-to-use note (e.g., pointing to write endpoints), so it falls short of a 5.

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

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

Annotations already establish the safe read profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the burden is lighter. The description adds real behavioral value by disclosing that this is a multi-endpoint dispatcher and naming the three operations, which tells the agent what capabilities actually live behind this single tool.

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?

Three compact sentences with no filler; the scope and endpoint inventory come first, followed by the usage and discovery hints. Every clause earns its place.

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?

For a dispatcher tool with no output schema, it covers endpoints, the required parameter source, and the discovery path. It does not describe what the calls return (e.g., whether download yields a package URL or file), a minor gap given the endpoint names are self-explanatory.

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 100%, so all four parameters are already documented, including the note that `name` comes from list_endpoints. The description reinforces the `name` semantics and adds the concrete discovery call, but this borders on usage guidance rather than adding new parameter meaning — baseline 3 applies.

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?

States a specific verb and resource (read operations on the Fivetran connector SDK) and enumerates the three endpoints it dispatches to, so the agent knows exactly what surface is covered. Combined with the resource-specific name, it is clearly distinguishable from the other '_read' siblings.

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?

Explains the dispatch mechanism ('Pass the endpoint name in `name`') and routes the agent to the discovery alternative ('Call list_endpoints(category='connector-sdk') for the full list'). It lacks an explicit when-not-to-use statement, but the operational context is clear.

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

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 covered. The description adds the useful dispatch mechanism (endpoint name multiplexing), but says nothing about auth requirements, rate limits, or pagination behavior.

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 tight sentences with zero waste. The purpose and endpoint list are front-loaded, followed by the required routing instruction.

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?

For a dispatcher tool with no output schema, the description adequately explains the name-multiplexing mechanism and how to discover valid values. It stops short of explaining how body/query/path_params vary per endpoint, though the schema documents those fields.

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 coverage is 100% and the `name` property description already explains it comes from list_endpoints, so the schema carries the load. The description restates rather than enriches the parameter meaning, so the baseline 3 is appropriate.

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?

States a specific verb and resource ('Read operations on Fivetran destinations') and enumerates all six concrete endpoints it dispatches to. The category scoping clearly distinguishes it from sibling *_read tools like connections_read or users_read.

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?

Gives explicit routing instructions: pass the endpoint name in `name` and call list_endpoints(category='destinations') to discover valid values. It does not state when NOT to use this tool versus a dedicated endpoint tool, but the category restriction is clear from context.

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

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 covered. The description adds useful behavioral context: this is a dispatcher spanning exactly three named endpoints and requires discovery through list_endpoints. It does not cover auth or rate-limit behavior, but that is reasonable given the annotations.

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?

Three short sentences, front-loaded with the purpose and immediately followed by the key invocation instruction and discovery route. Every sentence earns its place.

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?

For a read-only dispatcher, the description supplies the essential calling information: the covered endpoint names, where to find the full list, and how to pass the endpoint name. It does not describe return shape, but the tool is read-only and has no output schema, so this is a minor gap.

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 coverage is 100%, and the schema already documents `name` as coming from list_endpoints. The description repeats that guidance and provides the three endpoint names as examples, but adds no syntax or constraints for `body`, `query`, or `path_params`. Baseline 3 is appropriate when the schema does the heavy lifting.

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: read operations on Fivetran external logging. It names the three covered endpoints and clearly scopes the tool to that resource group, making it distinguishable from sibling *_read tools.

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?

It tells the agent to pass the endpoint name in `name` and to call list_endpoints(category='external-logging') for the full list. This gives clear usage context, though it does not explicitly state when not to use this tool versus other resource-read siblings.

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

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 covered. The description adds the dispatcher pattern (name drives which endpoint runs), which is useful, but says nothing about return shape, pagination, or error behavior.

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 tight sentences with no filler, and the core purpose is front-loaded before the calling convention. Sized well for a thin dispatcher-style tool.

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?

For a generic read dispatcher with full schema coverage and no output schema, the description supplies the essential calling convention. It is nearly complete, missing only any note on the return payload or how to interpret the single endpoint's output.

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 100%, so the schema documents all four parameters and establishes a baseline of 3. The description reinforces the role of `name` and its source (list_endpoints) but adds little beyond what the schema already states.

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?

States a specific verb (read) and resource (Fivetran external secrets managers entities) and names the single underlying endpoint (list_esm_entities). It is distinguishable from the sibling external_secrets_managers_read by the 'entities' sub-resource, though the distinction is subtle and not called out explicitly.

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?

Gives concrete operational guidance: pass the endpoint name in `name` and call list_endpoints with category='external-secrets-managers-entities' to discover valid values. However it never states when to prefer this tool over the base external_secrets_managers_read sibling, so the when-not condition is left to inference.

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

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 covered. The description adds that this is a multi-endpoint dispatcher, which is useful context, but says nothing about return format or per-endpoint behavior.

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 tight sentences, front-loaded with the resource and endpoint list, followed by the mechanical guidance on how to populate `name`. No filler.

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?

For a generic dispatcher with no output schema and fully documented parameters, the description supplies exactly what an agent needs: the endpoint names, where to put them, and how to discover the full list. Minor gap in not distinguishing it from the entities_read sibling.

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 100%, so all four parameters are already documented in the schema. The description only reinforces how `name` selects the endpoint, adding no syntax or format detail beyond the schema. Baseline 3 applies.

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?

States a specific verb (read) and resource (Fivetran external secrets managers) and enumerates the three concrete endpoints it dispatches to. It is distinguishable from most siblings, though get_esm_entities overlaps slightly with the external_secrets_managers_entities_read sibling.

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?

Gives clear operational guidance: pass the endpoint name in `name` and call list_endpoints(category='external-secrets-managers') to enumerate valid values. It does not state when-not to use it or how it differs from the entities_read sibling, so it falls short of a full 5.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so safety is covered. The description adds a non-obvious behavioral trait beyond that: the returned schema is dynamically reshaped by the `service` parameter for create/modify endpoints. It stops short of noting rate limits or caching, but the dynamic-output disclosure is genuine added value.

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 sentences, front-loaded with purpose followed by the parameter nuance. The second sentence is dense (four endpoint names plus the splice concept) but every clause earns its place. No filler or restated title.

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?

With no output schema, the description correctly enumerates the return shape (description, parameters, request body, response schema), and both inputs are fully covered by a 100%-coverage schema. For a simple read-only 2-param metadata tool this is essentially complete; only the sibling routing is arguably missing.

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 coverage is 100% and both parameters are documented in-schema with examples. The description mostly restates the `service` semantics already present in the schema ('Only meaningful for create/modify connection or destination endpoints'), so it adds only marginal meaning beyond structured data — the baseline 3.

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?

Clear specific verb + resource: 'Return the full schema for a Fivetran endpoint,' and it enumerates exactly what is returned (description, parameters, request body schema, response schema). It does not, however, differentiate itself from siblings like list_endpoints or the various *_read tools within the description text itself — that routing hint lives only in the parameter schema.

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?

The description gives explicit conditional guidance for one input: pass `service` on create_connection/modify_connection/create_destination/modify_destination to splice in per-service config. It gives no guidance on when to call get_schema versus list_endpoints or the *_read siblings, so tool-level usage is only implied.

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

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

Annotations already establish the safe read-only profile (readOnlyHint=true, destructiveHint=false), so the bar is lower. The description adds genuinely useful behavior beyond that: this is a fan-out router with 6 discrete sub-endpoints, and the required `name` value comes from list_endpoints. It stops short of noting per-endpoint input differences (e.g., which need path_params or body).

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?

Three tightly packed sentences with zero waste: purpose and endpoint list first, then the invocation contract, then the discovery pointer. Front-loaded and easy to scan.

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?

For a router-style tool with full schema coverage, annotations, and no output schema, the definition is largely sufficient: it names all endpoints and the discovery path. The only minor gap is not flagging that different sub-endpoints require different path_params or body payloads.

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 100%, so body/query/path_params semantics are fully documented in the schema, establishing a baseline of 3. The description only reinforces that `name` is an endpoint identifier from an enumerated set and does not add format detail beyond the schema.

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?

States a specific verb+resource (read operations on Fivetran groups) and enumerates the exact 6 endpoints it dispatches to, so the agent knows precisely what surface it covers. It is clearly distinguishable from sibling *_read tools covering other resources.

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?

Explains the invocation contract (pass the endpoint name in `name`) and routes the agent to list_endpoints(category='groups') for discovery. It gives clear context for using the tool but does not explicitly state when NOT to use it versus calling list_endpoints or a more specific sibling directly.

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

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 covered. The description adds that this is a thin dispatcher over exactly two read endpoints, which is useful context, but it says nothing about response shape or rate limits.

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?

Three short sentences, front-loaded with the resource and scope, then the calling convention, then the discovery step. Nothing is padding.

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?

For a read-only dispatching wrapper with no output schema, the description covers what the tool is, how to select an endpoint, and where to enumerate options. It does not explain how body/query/path_params interact with the two read endpoints, which is a minor gap given they are largely irrelevant for GETs.

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 100%, so the schema already documents all four parameters; baseline is 3. The description adds that `name` must be one of the two named endpoints sourced from list_endpoints, which is a small increment over the schema text but not new detail on body/query/path_params.

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?

States a specific verb (read) and resource (Fivetran hybrid deployment agents) and enumerates the exact two endpoints it dispatches to, so an agent knows what this wraps. It distinguishes itself from generic siblings by naming the resource, though it doesn't explicitly contrast with other *_read tools.

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?

Tells the agent to pass the endpoint name in `name` and to call list_endpoints(category='hybrid-deployment-agents') to discover valid values. That is a clear, actionable usage path with no ambiguity, though there is no when-not-to-use guidance.

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

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

Annotations already cover the safety profile (readOnly, non-destructive), and the description goes further by disclosing that deprecated endpoints are hidden unless include_deprecated=true and by explaining the `callable: bool` field — that false means the endpoint is not reachable through this MCP. That is real behavioral context an agent cannot get from the annotations.

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?

Dense and front-loaded — purpose first, then the three argument modes, then the return-shape caveat, then deprecation behavior. Every sentence carries distinct information with no filler.

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?

Despite having no output schema, the description describes the return shapes for the no-argument and filtered cases and explains the callable flag, so an agent knows what it will receive. Nothing needed to call this tool correctly is missing.

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 coverage is 100%, so the baseline is 3, but the description adds value beyond it: it gives a concrete category example ('connections'), clarifies that omitting the category yields counts, and describes the return payload shape for each mode. It stops short of exhaustive syntax detail, which the schema already supplies.

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?

States a specific verb and resource ('Discover Fivetran API endpoints') and unmistakably separates itself from every *_read sibling by being a meta-discovery tool rather than a data reader. The two operating modes are named immediately.

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?

Explicitly routes the agent by argument: no arguments returns counts, `category` narrows to one resource family, `search` substring-matches across name/summary/path. Each mode's trigger condition is spelled out, leaving nothing to inference.

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

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 safe-read profile is covered. The description only adds that the tool is scoped to a curated two-endpoint set; it says nothing about pagination, response shape, or auth, so with annotations carrying the safety burden a 3 is appropriate.

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 tight sentences, zero filler, with the core purpose and endpoint list front-loaded before the discovery hint. Every clause earns its place.

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?

For a read-only wrapper over two endpoints with full schema coverage and no output schema, the description supplies enough to invoke it correctly: valid endpoint names and how to discover more. It could note that `body` is only needed for write-style endpoints, but the schema already covers that.

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 coverage is 100%, so the baseline is 3. The description adds value beyond the schema by enumerating the two concrete endpoint names accepted by `name` (the schema has no enum), and by pointing to list_endpoints as the source of valid values.

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?

States a specific verb (Read) and resource (Fivetran metadata), and names the two endpoints it covers (metadata_connector_config, metadata_connectors). This lets an agent distinguish it immediately from siblings like connections_read or users_read, which target other resource groups.

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?

Tells the caller to pass the endpoint name in `name` and to call list_endpoints(category='metadata') to discover the full set, which is clear procedural guidance. It stops short of explicit when-not-to-use or exclusion conditions, so it is not a full 5.

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

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 only the endpoint count/names, which is scope information rather than new behavioral detail; nothing is said about pagination, error behavior on an unknown endpoint, or auth requirements.

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?

Three short sentences, no filler, and the resource scope is front-loaded before the dispatch instructions. The parenthetical endpoint list is compact, though the middle clause slightly interrupts the flow between purpose and guidance.

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?

For a generic by-name dispatcher with no output schema, the description supplies what an agent actually needs: the resource scope, the dispatch mechanism, and the way to discover valid endpoint names. Only minor gaps remain, such as what happens when an invalid `name` is passed.

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 100%, so all four parameters are already documented in the schema. "Pass the endpoint name in `name`" restates the schema and adds no format or constraint detail beyond what is there. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb and resource ("Read operations on Fivetran private links") and narrows the scope further by enumerating the exact two endpoints it wraps. This lets an agent distinguish it from the other *_read dispatchers (proxy_read, webhooks_read, etc.) without opening any schema.

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?

Gives the concrete discovery path: "Call list_endpoints(category='private-links') for the full list." That tells the agent how to obtain valid `name` values. It does not state when-not to use this group versus a sibling read group, so it stops short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and a closed-world scope, so the safety profile is covered. The description adds the dispatch behavior (3 named endpoints, discovery via list_endpoints), but says nothing about response shape, pagination, or per-endpoint differences beyond the names.

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 sentences, zero filler, and the scope plus the three valid endpoint names are front-loaded ahead of the discovery hint. Nothing could be cut without losing routing 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?

For a generic dispatch tool whose annotations carry the safety profile and which has no output schema, the description supplies the essential pieces: what it covers, how `name` maps to endpoints, and where to get the authoritative list. Only per-endpoint distinctions or response notes are missing.

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 coverage is 100%, so body/query/path_params/name are all documented in the schema itself. The description only clarifies that `name` must be one of the three proxy endpoints from list_endpoints, which mildly reinforces but does not extend the schema. Baseline 3 applies.

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?

States a specific verb (read), the resource (Fivetran proxy), and enumerates the three covered endpoints (get_proxy_agent, get_proxy_agent_connections, get_proxy_agent_details). This is enough for an agent to distinguish it from the many sibling *_read dispatchers, which are scoped to other categories.

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?

Explicitly tells the agent to pass the endpoint name in `name` and to call list_endpoints(category='proxy') for the full list, which is the routing path for this dispatcher. It stops short of saying when NOT to use it (e.g., that other categories belong to sibling tools), leaving that to inference from the sibling names.

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

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 covered by structured data. The description usefully adds the dispatch-by-name pattern and the size of the endpoint group, but says nothing about pagination, auth requirements, or the shape of returned data.

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?

Three short sentences, front-loaded with the verb/resource and scope, then the required parameter, then the discovery call. Every sentence carries actionable information with no filler.

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?

For a parameterized dispatcher over a single endpoint, the description plus the 100%-covered schema give an agent enough to invoke it correctly; the discovery pointer closes the main gap. It is slightly thin on return shape, but no output schema exists and the description need not carry return semantics.

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 100%, so all four parameters (name, body, query, path_params) are already documented in the schema, giving a baseline of 3. The description reinforces that `name` must come from list_endpoints, but adds no syntax, format, or constraint detail beyond that.

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 names a specific verb and resource (read operations on Fivetran public endpoints) and discloses the exact scope of the group (1 endpoint: metadata_public_connectors). It partially distinguishes itself from siblings by pointing at list_endpoints, though the generic 'public' group name is not self-explanatory.

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?

It explains the dispatch mechanism ('Pass the endpoint name in `name`') and routes the agent to list_endpoints(category='public') to discover valid values. That is clear usable context, but there is no guidance on when to prefer this tool over sibling *_read tools or when it would fail.

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

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 covered. The description adds the scope constraint that only one endpoint exists in this group, but says nothing about pagination, auth, or response shape.

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 short sentences, front-loaded with the resource and endpoint count, then the invocation rule. Minimal waste, though the `name` instruction slightly restates the schema.

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?

For a read-only dispatcher with no output schema, the description supplies what an agent needs: the resource scope, the endpoint count, and the discovery mechanism. It could note that responses are read-only endpoint payloads, but nothing essential is missing.

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 100%, so all four parameters are already documented. The description reinforces that `name` carries the endpoint identifier and points to list_endpoints for valid values, but adds no format or constraint details beyond the schema. Baseline 3 applies.

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?

States a specific verb+resource: read operations on Fivetran roles, and names the sole endpoint (list_all_roles). An agent can distinguish it from the other *_read dispatchers by the 'roles' resource, though it does not explicitly contrast itself with a sibling.

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?

Clearly instructs how to select the endpoint ('Pass the endpoint name in `name`') and where to discover the valid values ('Call list_endpoints(category='roles')'). It gives forward routing rather than when-not-to-use exclusions, but the context is unambiguous.

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

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 covered. The description adds genuine value beyond that by disclosing this is a dispatcher with exactly two read endpoints and by pointing to the discovery flow (list_endpoints). It does not mention pagination or return shape, but with no output schema and a read-only profile that is a modest gap.

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 short sentences, front-loaded with the scope and endpoint count, followed by the single required action and the discovery hint. No filler or repetition.

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?

For a read-only dispatcher with no output schema, the description supplies the endpoint list, the `name` requirement, and the list_endpoints discovery path. The remaining gap is that it never explains how to supply identifying values (e.g., the path parameter for get_system_key_details), but the schema's path_params field partially covers that.

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 100%, so all four parameters are already documented in the schema. The description only restates the `name` semantics (endpoint name from list_endpoints) and says nothing about how body/query/path_params should be filled for these GET-style endpoints, so it adds little beyond the schema. Baseline 3 applies.

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?

States a specific verb and resource (read operations on Fivetran system keys) and even enumerates the two underlying endpoints (get_system_key_details, get_system_keys). An agent can distinguish this from sibling groups like users_read or webhooks_read purely from the name plus this enumeration, without opening the schema.

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?

It gives a concrete routing instruction: 'Pass the endpoint name in `name`' and 'Call list_endpoints(category='system-keys') for the full list.' That is clear usage context and names a discovery alternative, though it never states when NOT to use this tool (e.g., for write operations, which live elsewhere).

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

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

Annotations already establish readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that this is a dispatcher requiring an endpoint name sourced from list_endpoints, but says nothing about auth requirements, pagination, or per-endpoint prerequisites (e.g. path_params for membership lookups).

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?

Three short sentences, front-loaded with the scope and endpoint inventory, followed by the two invocation facts an agent needs. Every sentence earns its place with no restatement of the name or annotations.

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?

For a multi-endpoint dispatcher with no output schema, the description supplies the endpoint inventory and the discovery path, which is the core of what an agent needs. It leaves per-endpoint parameter requirements and response shape unstated, which is a modest but real gap.

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 coverage is 100%, so the baseline is 3, but the description goes beyond the generic schema text by enumerating the valid values for `name` and pointing at list_endpoints as the authority for that value set. It still does not explain which endpoints require path_params or query, leaving the nested-object parameters to the schema.

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?

States a specific verb (read operations) and resource (Fivetran teams), and enumerates the eight concrete endpoints reachable through the dispatcher, so the agent knows exactly what is behind the name. It distinguishes itself from siblings only implicitly by resource scope; there is no explicit contrast with users_read or groups_read, which would be needed for a 5.

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?

Gives clear operating instructions: pass the endpoint name in `name` and call list_endpoints(category='teams') for the full list. This is actionable context without exclusions, but it does not say when a caller should prefer a different *_read sibling over this one.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds a real behavioral trait beyond that: this is a dispatch/proxy tool that fans out to exactly 2 endpoints selected via `name`, plus the workflow needed to enumerate them. It stops short of describing return shape or pagination.

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 packed sentences with no filler; the resource scope and the two endpoints are front-loaded before the dispatch instruction and the discovery hint.

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?

For a multiplexed read proxy with no output schema and 100% schema coverage, the description supplies the essential context: what the tool covers, the number and names of endpoints, and how to discover valid `name` values. It omits any per-endpoint description and any routing hint versus transformations_read, which are the remaining gaps.

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 coverage is 100%, so every parameter is already documented, and the schema's own `name` description already points to list_endpoints. The description only restates that the endpoint name goes in `name`, adding marginal value over the structured fields, so the baseline of 3 is appropriate.

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?

States a specific verb and resource ('Read operations on Fivetran transformation projects') and enumerates the two underlying endpoints (list_all_transformation_projects, transformation_project_details), so the agent knows the scope. It does not, however, differentiate itself from the close sibling transformations_read, which handles a different but similarly named resource.

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?

Gives a concrete discovery step: call list_endpoints(category='transformation-projects') to obtain valid `name` values, and states that the endpoint name must be passed in `name`. This is clear usage context, but there are no exclusions or guidance on when to prefer this over transformations_read or the other *_read siblings.

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

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 covered. The description adds the useful fact that this is a 4-endpoint dispatcher and how to discover endpoints, but says nothing about pagination, auth, or error behavior.

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?

Three tight sentences, no filler, with the core purpose front-loaded before the operational instructions. Every clause earns its place.

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?

For a dispatcher tool with a fully documented schema and annotations covering safety, the description supplies the essential missing piece: which endpoint names exist and where to get the authoritative list. Pagination and per-endpoint argument requirements are left implicit, which is a minor gap.

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 coverage is 100%, so the baseline is 3, but the description goes further by defining the valid domain of `name` (the four listed endpoints) and pointing to list_endpoints for discovery. It still leaves body/query/path_params usage entirely to the schema.

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?

States a specific verb+resource ('Read operations on Fivetran transformations') and enumerates the four endpoints it multiplexes, which lets an agent map an intended call to this tool without opening the schema. It does not explicitly contrast with adjacent siblings like transformation_projects_read, so it falls just short of a 5.

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?

Gives concrete operational routing: pass the endpoint name in `name`, and call list_endpoints(category='transformations') to enumerate valid endpoints. That is genuine when/how guidance, but it offers no exclusion criteria telling the agent when a sibling read tool is the better choice.

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

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

Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds valuable dispatch behavior: it reveals the tool multiplexes 8 named endpoints and that the caller must pass the endpoint name in `name`, which is operational context beyond annotations.

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?

One compact paragraph, front-loaded with purpose, then the endpoint list, then call instructions. No filler; the endpoint list is dense but necessary for dispatch.

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?

Given no output schema and full parameter schema coverage, the description supplies the essential dispatch mechanics and points to list_endpoints for full details. It does not explain per-endpoint body/query/path requirements, but the schema covers those fields adequately.

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 coverage is 100%, so the baseline is 3. The description adds meaning for the `name` parameter by listing the exact 8 endpoint names, supplementing the schema's generic 'from list_endpoints' text. Other parameters are left to their schema descriptions.

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?

States 'Read operations on Fivetran users' and enumerates the 8 endpoints, so the verb, resource, and scope are clear. It does not explicitly contrast with sibling resource-read tools, but the tool name and endpoint list make its domain unambiguous.

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?

Provides a discovery hint (call list_endpoints(category='users') for the full list) but does not state when to choose users_read over sibling *_read tools or when not to use it. Usage is implied by the users domain but not explicitly guided.

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

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.

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.

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.

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.

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.

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.