Server Quality Checklist

Tool Scores

• connector_sdk_readB
  3.3/5.0
  Behavior3/5

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

  It implies read-only behavior by stating 'Read operations', but does not explicitly guarantee no side effects or discuss any limitations or permissions.

  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?

  The description is concise, covering the essential information in two sentences without unnecessary verbosity.

  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?

  It lists the available endpoints and directs users to list_endpoints for more details, but lacks information about output format, error handling, or endpoint-specific parameters.

  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?

  The description clarifies that 'name' refers to the endpoint name, but provides no additional detail on the other parameters beyond the generic schema descriptions.

  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 clearly states it handles read operations for the connector SDK and lists the specific endpoints, making its purpose unambiguous.

  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?

  It provides minimal guidance on when to use this tool versus others; it only hints that it's for read operations and suggests using list_endpoints for the full list, but does not explicitly state when to prefer this over other read tools.

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

• external_secrets_managers_readA
  3.7/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden. It clarifies that the tool is a multi-endpoint read wrapper and that the endpoint name must be passed via `name`. It does not mention response formats, error behavior, authorization requirements, or potential side effects, though 'read' implies safety.

  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?

  The description is two sentences, front-loaded with the core purpose and endpoint list, and contains no filler or repetition. Every sentence contributes to understanding or usage.

  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?

  The tool is a generic dispatcher for three read endpoints with no output schema and no annotations. The description gives the endpoint list and points to list_endpoints for more, but does not explain what each operation returns or how to construct path_params/query for specific endpoints, leaving a moderate gap.

  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?

  Input schema coverage is 100%, so the baseline is 3. The description adds minimal extra parameter meaning beyond restating that `name` selects the endpoint, which is already documented in the schema.

  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 clearly states 'Read operations on Fivetran external secrets managers' and lists the three supported endpoints (get_esm_details, get_esm_entities, list_esms), making the tool's purpose explicit and distinguishing it from other resource-specific read tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description advises calling list_endpoints(category='external-secrets-managers') for the full endpoint list, which is useful. However, it does not explicitly explain when to choose this tool over sibling alternatives like external_secrets_managers_entities_read, nor how to select among the three endpoints.

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

• connections_readA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden of disclosing behavior. It does state this is a read-only operation ('Read operations'), and it lists the endpoints, which implies safety. However, it does not describe any error behavior, rate limits, or what happens if an invalid endpoint name is passed. It's adequate for a read-only dispatcher but not rich in detail.

  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?

  The description is a single sentence that packs the core purpose, endpoint list, and usage instruction. The instruction to call list_endpoints for the full list is efficient and avoids duplication. No wasted words.

  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?

  Given the tool's generic dispatcher nature and 100% schema coverage, the description covers the essential usage pattern. It lists 9 of 10 endpoints, omitting one but providing a way to discover it. There's no output schema, but for a read dispatcher, the description adequately sets expectations. It could have mentioned response format, but that's likely endpoint-specific.

  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 coverage is 100%, meaning all four parameters are described in the schema. The description adds that `name` should be an endpoint name from list_endpoints, which is useful context beyond the schema. However, it does not explain the interplay between `body`, `query`, and `path_params` for different endpoints, so it adds modest value but does not fully compensate for the generic schema descriptions.

  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 clearly states this tool handles read operations on Fivetran connections and lists the 9 specific endpoints it maps to. It also mentions passing the endpoint name in `name`, which clarifies its generic dispatch nature. However, it doesn't explicitly distinguish itself from sibling tools beyond the 'connections' scope, and the final '+ 1 more' is slightly vague, though acceptable since it directs to list_endpoints for the full list.

  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?

  The description explicitly tells the user to pass the endpoint name in `name` and directs to call `list_endpoints(category='connections')` for the full list, providing clear how-to guidance. It doesn't explicitly state when NOT to use this tool (e.g., for write operations, which are presumably handled elsewhere), but the sibling list includes separate tools for other resource types, so the context is reasonably clear.

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

• external_secrets_managers_entities_readA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden. It discloses that it's a read operation (non-destructive) and that it requires an endpoint name, but doesn't detail response format, pagination, or error behavior. It adds some context beyond the schema but not extensive.

  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 sentences, front-loaded with the purpose, and no wasted words. It efficiently conveys the essential information.

  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?

  Given the tool is a generic read wrapper with a single endpoint, the description is complete enough. It references list_endpoints for the full list, which is a good pattern. No output schema exists, but the description doesn't need to explain return values for a list operation.

  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 all parameters. The description adds the key semantic that `name` is the endpoint name and that body is for POST/PATCH (though this is a read tool, so body may be irrelevant). It doesn't add much beyond the schema, but the baseline is 3 due to high coverage.

  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 clearly states it performs read operations on Fivetran external secrets managers entities, specifically listing ESM entities. It distinguishes from siblings by naming the specific endpoint (list_esm_entities) and the category, 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.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It instructs to pass the endpoint name in `name` and directs to call list_endpoints for the full list, providing clear usage context. It doesn't explicitly state when not to use it, but the guidance is sufficient for a generic read tool.

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

• metadata_readA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden. It discloses that the tool is a 'read operation' which implies non-destructive behavior, but it does not detail any additional behavioral traits (like authorization requirements, rate limits, or what happens with invalid endpoint names). The limited scope (2 endpoints) is mentioned, which adds some context.

  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?

  The description is two sentences, tightly packed with essential information. It front-loads the purpose and immediately tells the user how to get valid endpoint values. No filler or redundant phrasing.

  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 simple read tool with no output schema, this description is sufficiently complete. It names the two endpoints, tells how to discover them, and explains the parameter usage. The tool has a clear scope and the description covers it well, though it could mention response format or error handling, but that is not essential for read-only endpoints.

  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?

  The schema covers 100% of the parameters, each with descriptions. The description adds a specific rule for the `name` parameter (use endpoint names from list_endpoints), but body/path_params/query semantics are already clear from the schema. Baseline of 3 is appropriate since the schema does significant work, but the description only adds a small tip about `name`.

  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 clearly states the tool performs read operations on Fivetran metadata and names two specific endpoints. It distinguishes itself from the many sibling read tools (e.g., account_read, connections_read) by specifying the 'metadata' category. It doesn't fully differentiate between the two metadata endpoints, but the explicit verb + resource + scope is clear.

  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?

  The description tells the user to pass the endpoint name in the `name` parameter and to call list_endpoints(category='metadata') for the full list. This provides clear guidance on how to identify the correct endpoint. It doesn't explicitly say when not to use this tool versus alternatives, but the category-based instruction gives adequate context for selection.

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

• transformations_readA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. 'Read operations' honestly discloses the non-mutating nature, and 'Call list_endpoints(category='transformations') for the full list' transparently admits the endpoint list can be expanded. However, it doesn't disclose response behavior, error cases, rate limits, or the relationship between the 4 endpoints and their respective path_params requirements, leaving the agent to discover these details at runtime.

  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?

  Three purposeful sentences, each earning its place: what the tool does, how to pass the required param, and where to find more endpoints. Front-loaded with the most important information and zero redundancy—an exemplary pattern.

  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 moderately complex facade tool (4 endpoints, 4 params, no output schema), the description does well: it names the endpoints, explains the dispatch mechanism, and routes discovery to list_endpoints. The main gap is that with no output schema, the agent still has no expectation of return shapes, and the description could hint at which endpoints need which path_params—but this is honestly the best of the dimensions given the abstraction's inherent complexity.

  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 baseline of 3 applies. The description adds marginal value by clarifying that `name` is a dynamic endpoint selector ('Pass the endpoint name in `name`'), which pairs well with the schema's 'Endpoint name within this resource:action group (from list_endpoints)'. But the description doesn't add semantics for body, query, or path_params beyond the schema, which already documents the {connectionId}, {groupId} placeholder pattern.

  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 uses a specific verb+resource pattern ('Read operations on Fivetran transformations') and adds concrete scoping by enumerating the 4 endpoints. It's clear and specific, but it doesn't explicitly distinguish itself from sibling tools like transformation_projects_read, so the purpose is clear without being fully differentiated.

  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?

  The description provides clear operational context: pass the endpoint name in `name` and call list_endpoints(category='transformations') for the full list. The cross-reference to a sibling tool enables the agent to choose correctly, and the schema note 'within this resource:action group' clarifies scope. However, it lacks explicit when-not-to-use guidance or a contrast with alternatives like transformation_projects_read.

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

• external_logging_readA
  3.9/5.0
  Behavior2/5

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

  There are no annotations to rely on, so the description carries the full burden of disclosing behavior. While it identifies that this is a read operation (implying non-destructive), it does not detail what each endpoint actually returns, any required authentication, or the structure of responses, leaving behavioral expectations vague.

  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?

  The description is a single, dense, front-loaded sentence that immediately states the purpose, lists the specific endpoints, and gives two crucial instructions (pass the endpoint name, use list_endpoints). There is zero wasted content; every clause earns its place.

  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?

  Given the tool's multi-endpoint nature, the description provides the essential mapping mechanism (name parameter) and a pointer to the authoritative list. It does not need to detail return values since there is no output schema and the tool is a read operation, but this is a minor gap given the absence of annotations and output schema; still, it covers the core guidance needed to invoke endpoints correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema already provides 100% coverage for all parameters, including descriptions for body, query, and path_params. The description adds the critical semantic that 'name' selects among three endpoints and that 'body' is required specifically 'for POST/PATCH endpoints', linking parameters to the tool's internal multi-endpoint logic and going slightly beyond what the schema states.

  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 clearly identifies the tool as read operations for Fivetran external logging, enumerating the three specific endpoints it covers, which distinguishes it from sibling read tools that target other API resource categories. It uses specific verbs ('get', 'list') and explicitly lists the endpoint names.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly instructs the agent to pass the endpoint name and to call list_endpoints(category='external-logging') to get the full list, providing direct guidance for tool selection and usage. This adequately directs usage and explains the mechanism for discovering valid endpoint names.

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

• groups_readA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden, but it does not disclose behavioral details such as pagination, rate limits, or the shape of the response. It does add value by listing the six endpoints and explaining the dynamic routing mechanism, which is not obvious from the schema alone. However, it does not mention whether any of these read operations have side effects (e.g., generating SSH keys) or require specific authentication, which could be relevant.

  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?

  The description is two sentences and immediately gets to the point. It front-loads the purpose, lists the supported endpoints in parentheses, and gives a clear call to action. Every sentence earns its place, and the length is appropriate for a tool that wraps six endpoints.

  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?

  The description covers a lot of ground for a tool that wraps six endpoints, and the pattern of pointing to list_endpoints for the full list is a good discovery mechanism. It is slightly less complete because it does not mention the response format, which could be a list of objects for some endpoints, but the agent is told to use list_endpoints for more details. Given that the tool is a generic wrapper, the description is rather complete, though an example of how to pass path_params would be nice.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100% for the generic parameters (name, body, query, path_params), and the description adds critical context by explaining how `name` is used to route to an endpoint. This is a bonus. However, the description does not document the specific parameters for each endpoint, which could leave the agent guessing. The description partially compensates by telling the agent to call list_endpoints for the full list, so it gets credit for directing the agent to authoritative schema information.

  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 clearly defines the tool as handling 'Read operations on Fivetran groups' covering 6 specific endpoints, which distinguishes it from sibling tools. However, the connection to actual endpoints is indirect since the description focuses on a generic wrapper rather than a specific action; the comparison to siblings like connections_read and users_read narrows scope. It rates slightly below a 5 because the name is read-centric but the underlying operations, like list_all_connections_in_group, slightly blur the boundary with the connections resource, whereas the description does not explicitly clarify these edge cases. The resource is clear: Fivetran groups.

  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?

  The instruction 'Pass the endpoint name in `name`. Call list_endpoints(category=''groups'') for the full list' provides clear, explicit usage context and references an alternative/discovery mechanism. While it does not explicitly say 'do not use for write operations', the description's 'Read operations' prefix and the endpoint list make this exclusion apparent. It is slightly less explicit than ideal because it does not mention sibling tools like connections_read for the case of listing connections within a group, but it does direct the agent to the right discovery call.

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

• hybrid_deployment_agents_readA
  4/5.0
  Behavior3/5

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

  The description clearly labels this as a read operation and names the two supported endpoints, which is the main behavioral trait. However, with no annotations provided, it does not disclose auth expectations, response format, error behavior, or whether paging is involved, leaving some burden unmet.

  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?

  Three short sentences deliver the core information: what the tool does, how to specify endpoints, and how to explore the full list. No filler or repetition.

  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 multi-endpoint read wrapper with four optional request-related parameters, the description provides enough context to know when and how to invoke. It could mention return values or offer more detail about the endpoints, but the available structure and guidance are reasonably 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 describes all four parameters. The description adds a useful reminder to pass the endpoint name in `name` and to consult list_endpoints, but the rest of the parameter semantics are adequately covered by the schema itself.

  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 begins with 'Read operations on Fivetran hybrid deployment agents', naming the exact resource and explicitly listing the two endpoint variants (get_hybrid_deployment_agent, get_hybrid_deployment_agent_list). This clearly distinguishes it from other read tools like users_read or connections_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 gives direct usage guidance: pass the endpoint name in `name` and use list_endpoints(category='hybrid-deployment-agents') to discover the full list. It does not explicitly state when not to use this tool, but the resource-specific focus implies the applicable context.

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

• private_links_readA
  4/5.0
  Behavior3/5

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

  With no annotations, the description successfully communicates the key read-only behavior and mentions the two available endpoints, which is important safety evidence. However, it describes no response shape, error behavior, or other operational caveats. It meets the minimum bar but could reveal more about what these two endpoints actually return.

  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 short sentences that lead with the purpose, enumerate the valid endpoints, and provide a discovery path. Every sentence earns its place; there is no filler or unnecessary elaboration.

  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?

  Given the tool complexity, full schema coverage, and the sibling *_read family, the description is sufficient: it names the resource, the exact endpoints, and how to obtain the full list. It lacks return format and explicit permission prerequisites, but those are less urgent for a read-only wrapper with a strong schema.

  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 coverage is 100%, so the input schema already documents name, body, query, and path_params. The description largely restates the name parameter ('Pass the endpoint name in `name`') and adds only a small discovery hint via list_endpoints(category='private-links'). The schema also mentions POST/PATCH endpoints for body, which sits awkwardly with a read-only tool; the description does not resolve this.

  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 opens with 'Read operations on Fivetran private links' and then names both available endpoints (get_private_link_details, get_private_links), giving a specific verb, resource, and precise activity. This clearly distinguishes the tool from the many 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.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear context for when to use this tool: it is the read-only wrapper for private links. It also directs the agent to list_endpoints(category='private-links') to discover the full endpoint list. It does not explicitly state when not to use it or name alternatives, but the resource naming across siblings makes the intended use obvious.

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

• public_readA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description bears the burden of conveying behavior. It states 'Read operations', indicating this is a non-destructive action, which is useful. However, it omits any details about authentication requirements, response format, error handling, or rate limits. The description does not contradict any annotations (none exist).

  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?

  The description is a single, focused sentence that front-loads the core purpose ('Read operations') and provides the essential directive for endpoint selection. There is no redundant information or 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 generic read tool with 4 parameters, 100% schema coverage, and no output schema, the description adequately covers the essentials: it specifies the scope (public), explains how to select endpoints, and references the full endpoint list. It does not describe return types or paging, but given the dynamic nature of the endpoint, this is acceptable.

  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 baseline is 3. The description adds the specific context that `name` is the endpoint name within this resource:action group and points to list_endpoints for the full list, but this duplicates the schema's mention of 'Endpoint name within this resource:action group (from list_endpoints)'. It does not add significant new meaning for other parameters like body, query, or path_params beyond what the schema already states.

  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 clearly states the tool's purpose: 'Read operations on Fivetran public' and identifies the specific endpoint 'metadata_public_connectors'. It distinguishes itself from sibling tools (which target specific categories like account_read or connections_read) by being a generic read for the public API group.

  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 explicitly instructs the agent to pass the endpoint name in `name` and to call `list_endpoints(category='public')` for the full list, which provides clear when-and-how usage. Though it doesn't explicitly state when to avoid this tool, the scoping to 'public' and reference to list_endpoints provide sufficient context for selecting alternatives.

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

• roles_readA
  4/5.0
  Behavior3/5

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

  Annotations are absent, so the description carries the full behavioral burden. It discloses this is a safe read-only operation ('Read operations') and reveals the internal implementation detail that this is a thin wrapper around an endpoint dispatcher. It does not describe response formats, pagination, or failure modes, but for a generic dispatcher with a single read-only endpoint, the disclosure is adequate, earning a solid 3.

  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 focused sentences, both earning their place: the first states what the tool covers, and the second gives the single critical usage instruction. Information is front-loaded with no filler or redundancy.

  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 generic dispatcher tool with 4 parameters, nested objects, and no output schema, the description with its pointer to list_endpoints for the authoritative endpoint list is sufficient. The agent can enumerate available endpoints dynamically rather than needing hardcoded documentation. A brief note about return format would push it to a 5.

  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%, establishing a baseline of 3. The description adds value by clarifying that `name` accepts an endpoint name from list_endpoints and that exactly one endpoint (list_all_roles) is available, which disambiguates the primary parameter's valid values. However, the description does not elaborate on `query`, `path_params`, or `body` semantics beyond what the schema already provides.

  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?

  Clear specific verb+resource: 'Read operations on Fivetran roles' with the concrete endpoint name 'list_all_roles'. It is clearly distinguished from sibling tools by naming the exact resource group (roles), and the instruction to use list_endpoints for the full endpoint list disambiguates 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.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly instructs how to invoke the tool ('Pass the endpoint name in `name`') and points to an alternative/complementary tool for endpoint discovery: 'Call list_endpoints(category='roles') for the full list'. This provides clear context and an explicit alternative, though it does not enumerate when-not-to-use cases since this is effectively the designated read dispatcher.

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

• system_keys_readA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral guidance. It notes the operation is 'read' and lists endpoints, but does not disclose return-value shape, auth needs, or potential error/pagination behavior. It's adequate but not rich.

  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 sentences; the first states what the operation does and the intention of 'name', the second tells the user how to discover the full endpoint list. Every phrase earns its place.

  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 generic read wrapper with no output schema, the description is reasonably complete. It identifies the 2 available endpoints, tells the user to pass the endpoint via 'name', and points to list_endpoints for a fuller list. Slightly more depth around when 'body' or 'query' are needed could improve yield, but overall it's sufficient.

  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 parameters 'body', 'name', 'query', and 'path_params' are all described. The description adds no new parameter meaning beyond pointing out that 'name' accepts an endpoint name and may come from list_endpoints. Baseline of 3 is appropriate.

  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 clearly states 'Read operations on Fivetran system keys' and names the two endpoints (get_system_key_details, get_system_keys). This makes the exact resource and action explicit, distinguishing it from sibling read tools for other Fivetran entities.

  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?

  The description gives actionable usage guidance: pass the endpoint name in 'name' and call list_endpoints(category='system-keys') for the full list. It doesn't explicitly say when to use vs. alternatives, but there are no close alternatives for system keys.

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

• transformation_projects_readA
  4/5.0
  Behavior3/5

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

  The phrase 'Read operations' makes clear this is non-destructive, which is valuable given zero annotations. However, it does not disclose any additional behavioral traits such as auth requirements, rate limits, response shape, or how the two endpoints differ in behavior.

  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?

  The description is two sentences long, front-loads the core purpose, and every sentence adds useful information. There is no waste or unnecessary repetition.

  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?

  Given the generic endpoint-router schema and no output schema, the description provides sufficient context by naming the two available endpoints and pointing to list_endpoints for full discovery. It could be more complete by describing what each endpoint returns or what path params are required, but the guidance is adequate for an agent to proceed.

  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 coverage is 100%, so the baseline is 3. The description adds the specific category value 'transformation-projects' for list_endpoints and reiterates the `name` parameter usage, but it does not add meaningful semantics for `body`, `query`, or `path_params` beyond what the schema already states.

  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 clearly identifies this as a read-only tool for Fivetran transformation projects and names the two exact endpoints it covers (list_all_transformation_projects, transformation_project_details). This is specific enough to distinguish it from sibling read tools like transformations_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 gives direct usage instructions: pass the endpoint name in `name` and call list_endpoints(category='transformation-projects') to get the full endpoint list. It clearly establishes the context for when to use this tool, though it doesn't explicitly mention alternative tools for non-read operations.

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

• users_readA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the transparency burden. It explicitly states the tool is read-only, which reveals a no-modification behavior, but it does not disclose details such as pagination, return types, or any special constraints. This is adequate but shallower than the calibration examples that add richer behavioral context.

  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?

  The description is compact and front-loaded, using two sentences to state purpose, list endpoints, and provide invocation guidance. No fluff exists; every sentence contributes to clear tool understanding.

  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 multi-endpoint read-only tool with no output schema, the description is complete enough: it names all six endpoints, tells users how to set `name`, and points to the dynamic source for the full list. It lacks deeper per-endpoint behavior, but that is reasonably deferred to list_endpoints and schema descriptions.

  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?

  The input schema covers 100% of parameters, including descriptions for name, body, query, and path_params, so a baseline of 3 is appropriate. The description adds useful context about how to choose the endpoint value, but does not significantly expand on parameter formats beyond what the schema already states.

  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 clearly states 'Read operations on Fivetran users' and enumerates the six specific endpoints, making the tool's action and resource unmistakable. This distinguishes it from sibling read tools by explicitly identifying the resource domain and listing available endpoints.

  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?

  The description gives clear operational guidance: pass the endpoint name in `name` and call list_endpoints(category='users') for the full list. It does not explicitly contrast with sibling tools or give when-not-to-use conditions, but the context is sufficient for selecting this tool for user read operations.

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

• webhooks_readA
  4.1/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden. It discloses that the tool is for read operations (non-destructive) and lists the two endpoints, but does not elaborate on response formats, pagination, authentication, or limitations.

  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 sentences, front-loaded with the main purpose. No wasted words; each sentence provides actionable information on usage.

  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?

  The two endpoints are mentioned but not explained in terms of what each returns or when to use one over the other. With no output schema, the description could have elaborated on behavior, though it does offer a pointer to list_endpoints for further details.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 adds value by explicitly instructing to pass the endpoint name in `name` and pointing to list_endpoints for valid values, which goes beyond the generic schema text.

  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 clearly states 'Read operations on Fivetran webhooks' with a specific verb and resource, distinguishing it from sibling read tools for other resources. It also names the two endpoints, making the tool's scope precise.

  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?

  The description provides clear context by instructing to call list_endpoints(category='webhooks') for the full list, which guides endpoint discovery. However, it does not explicitly state when not to use this tool or when to prefer a different resource-specific read tool.

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

• account_readA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of disclosing behavior. It explicitly states 'Read operations', which clearly indicates no side effects or modifications. This sufficiently communicates the read-only nature, though it doesn't mention potential errors or limits, which are not critical for a simple read tool.

  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?

  The description is concise, using just two sentences to convey purpose and usage. It avoids unnecessary detail and is well-structured, making it easy to parse and act upon.

  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?

  The description is complete for the tool's scope: it identifies the resource, action, endpoint selection method, and provides a pointer to list all endpoints. It does not elaborate on output format, but no output schema is expected, so this is acceptable.

  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?

  The description explains the `name` parameter (endpoint name) but does not add any meaning to `body`, `query`, or `path_params`. Since the schema already provides generic descriptions for these, the description adds marginal value beyond what is already in the schema, hence the baseline score of 3.

  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 clearly states the action ('Read operations') and the specific resource ('Fivetran account'), and it identifies the exact endpoint available (get_account_info). This makes the tool's purpose unambiguous and distinct from sibling tools that target other resources.

  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?

  The description provides explicit guidance on how to use the tool (pass the endpoint name in `name`) and directs users to list_endpoints(category='account') for the full list of endpoints. While it doesn't explicitly contrast with other read tools, the resource-specific context makes alternatives clear enough.

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

• destinations_readA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It discloses that these are 'Read operations', implying non-destructive behavior, but adds no further context about permissions, return formats, or error cases.

  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 concise sentences: the first states purpose and scope, the second gives the critical usage instruction. No filler or redundant detail.

  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?

  The description lists all endpoints, clarifies the mandatory name parameter, and points to list_endpoints for discoverability. In the absence of an output schema, it could have elaborated on return structures, but the endpoint names themselves convey expected data types.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, yet the description adds meaningful value by listing the six valid endpoint names for the `name` parameter, which would otherwise be an unconstrained string. This directly aids invocation.

  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 clearly states the tool's purpose: 'Read operations on Fivetran destinations' and enumerates all six covered endpoints, making it distinct from sibling 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.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides explicit usage instructions: 'Pass the endpoint name in `name`' and directs users to list_endpoints for the full endpoint list. However, it does not explicitly contrast this tool with alternatives for other resource categories, so it stops 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.

• proxy_readA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of transparency. It successfully communicates the non-destructive read-only nature and the three supported endpoints, providing baseline context. However, it doesn't disclose error behavior, authentication assumptions, or rate-limit implications, which would enrich the agent's understanding for edge cases.

  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?

  The description is exceptionally concise—two sentences—yet packs in the tool's purpose, the endpoint scope, and clear next-step instructions. Every phrase contributes to the agent's understanding without redundancy.

  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?

  Given the absence of an output schema and the tool's role as a dynamic dispatcher (relying on list_endpoints for full context), the description provides sufficient scaffolding for an agent to proceed effectively. While it could detail more about response shapes or error scenarios, the actionable direction to list_endpoints mitigates this gap and is appropriate for the tool's design.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Although the schema already covers parameter definitions at 100%, the description adds decisive value by specifying how to obtain valid endpoint names and that `name` is the required dispatcher field. This turns a generic schema into an actionable workflow, though it could have provided examples for the `query` or `path_params` usage.

  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 clearly states this handles 'Read operations on Fivetran proxy' and enumerates the three exact endpoints, which accurately reflects the tool's scope. It distinguishes itself from sibling tools by specifying the proxy resource and read-only nature.

  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?

  The instruction to 'Pass the endpoint name in `name`' and to 'Call list_endpoints(category='proxy') for the full list' provides actionable guidance on usage. However, it doesn't explicitly discuss when not to use this tool or mention alternatives, though the sibling tools imply clear resource separation.

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

• list_endpointsA
  4.3/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the transparency burden. It discloses default behavior (deprecated hidden) and return structure for the no-args case. However, it does not mention authentication, rate limits, or other operational aspects, though for a read-only discovery tool this may be sufficient.

  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?

  The description is two sentences, front-loaded with the core purpose, then explaining usage modes and defaults. Every sentence earns its place with no fluff or redundancy.

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

  Completeness5/5

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

  Given the tool's simplicity, the lack of an output schema, and no annotations, the description adequately covers all needed information: default return format, optional parameters, search behavior, and deprecated endpoint handling. It is complete for an agent to invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema covers all parameters with descriptions, but the tool description adds valuable context: category examples (e.g., 'connections') and search coverage (name, summary, path). This enhances understanding beyond the schema, justifying above baseline.

  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 clearly states the tool's purpose: 'Discover Fivetran API endpoints' with specific options for category and search. It distinguishes from sibling tools which are resource-specific read operations, as this is a discovery tool for endpoint metadata.

  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?

  The description implicitly guides usage by explaining behavior with no arguments, with category, and with search, as well as how to include deprecated endpoints. It doesn't explicitly name alternatives, but the context makes it clear this is the discovery tool while siblings are for specific resource reads.

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

• teams_readA
  4.4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It does a good job: it immediately demonstrates that this tool is a logical container for multiple read endpoints (8 listed), that `name` is the dispatcher, and that `list_endpoints` is the authoritative source for discovering them. It also implies read-only behavior ('Read operations') and avoids promising unsupported behavior. It doesn't cover error cases or rate limits, but for a family of GET-like endpoints, this is a reasonable and transparent disclosure. The only minor gap is not explicitly stating that there are no side effects or authentication details, but the read-only framing covers most practical needs. It doesn't contradict the (missing) annotations or schema.

  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?

  Exactly two dense, information-rich sentences. The first sentence states the tool's specific purpose and lists all 8 endpoints. The second gives a direct instruction to the agent ('Pass the endpoint name in `name`') and explicitly references the proper discovery mechanism. No fluff, 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?

  Given the tool's moderate complexity (1 required param, 3 optional, no enums, no output schema required), the description is quite complete: it explains what to do with `name`, where to find the full list, and even gives the specific endpoint names as examples. It doesn't explain return values, but with no output schema and a purely read-oriented concern, that's acceptable. The only missing piece is a note about read-consistency or respective error handling, but those are edge cases for this kind of tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 100%, so the structured data already documents each parameter. The description adds value by telling the agent that `name` should be an endpoint name from `list_endpoints(category='teams')`, and `path_params` will be filled with placeholders like `{connectionId}` and `{groupId}`. This bridges the gap between a generic `path_params` object and the actual dynamic segments in the API. The only reason it doesn't get a 5 is that it doesn't provide examples of what `body` or `query` might look like, but the schema already covers the basics.

  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?

  Purpose is explicitly stated as 'Read operations on Fivetran teams,' with a specific verb ('Read'), resource ('Fivetran teams'), and a concrete list of 8 endpoint names that anchor its scope. This clearly differentiates it from sibling tools like teams_write or teams_get, so an agent can immediately identify its purpose and scope.

  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?

  The description gives clear usage context by naming the exact endpoint function (`get_team_membership_in_connection`, etc.) and instructs the agent to pass the endpoint name in `name`. It also directs to `list_endpoints(category='teams')` for the full list, which serves as an alternative reference. However, it does not explicitly state when *not* to use this tool or mention read-only alternatives, though the 'Read operations' prefix and the explicit endorsement of the generic `list_endpoints` helper serve as a de facto exclusion criterion.

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

• get_schemaA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the behavioral disclosure burden. It explains that the tool returns a full schema and clarifies the special behavior of the `service` parameter (splicing in the per-service config shape for specific endpoint families). It does not mention side effects, but this is a read-only schema lookup and the behavior described is sufficiently transparent for its purpose.

  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 concise sentences, front-loaded with the primary purpose and immediately followed by the essential parameter guidance. Every sentence contributes meaningful information with no filler or redundancy.

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

  Completeness5/5

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

  For a simple schema-lookup tool with no output schema and no annotations, the description sufficiently covers the return contents and the nuanced `service` parameter behavior. It is complete enough for an agent to select and invoke the tool correctly, especially given the 100% parameter schema coverage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 meaningful semantic value beyond the schema by explaining that `service` is needed specifically for create/modify connection and destination endpoints to splice in the per-service config shape. The `name` parameter is also contextualized by the schema description referencing list_endpoints.

  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 uses a specific verb and resource: 'Return the full schema for a Fivetran endpoint' and enumerates the included content (description, parameters, request body schema, response schema). This clearly distinguishes it from sibling read tools like list_endpoints by focusing on schema introspection for a single endpoint.

  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?

  The description provides clear usage context by explaining when to pass the optional `service` parameter: on create_connection, modify_connection, create_destination, and modify_destination endpoints. It does not explicitly state when not to use this tool or name alternatives, but the schema parameter description ('Discover via list_endpoints') and the tool's unique purpose imply appropriate usage.

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