get_r_integration_integration_credentials

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

With no annotations, the description carries the behavioral burden, and it does establish read-only intent through 'Retrieve' and the explicit `GET` method. It also hints that query supports filters and pagination and that headers may be required, but it does not disclose authentication needs, response characteristics, or any side effects; the output schema presumably covers return 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?

The description is two sentences with no filler: it front-loads the purpose and endpoint, then gives compact placement guidance for the generic parameters. 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 generic HTTP-wrapper tool with no annotations and no schema detail, the description covers the core call mechanics and read-only nature, and the output schema handles return values. It is incomplete, though, because it does not distinguish this collection endpoint from the `_id` sibling, does not mention the body parameter, and does not state any prerequisites or authentication requirements.

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 0% and all parameters are generic additionalProperties containers, so the description's mapping of path_params to route IDs, query to filters/pagination, and headers to required headers adds essential meaning. However, it leaves the body parameter unexplained and does not enumerate specific query or path parameter names or formats, so compensation is only partial.

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 clearly states the action ('Retrieve integration credentials') and the exact HTTP endpoint (`GET /r/integration/integration_credentials`), making the resource and method unambiguous. It does not explicitly contrast with the `_id` variant, but the plural resource name and endpoint make the collection intent reasonably clear.

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 provides operational guidance on where to place path_params, query, and headers, but it does not say when to use this tool versus alternatives such as `get_r_integration_integration_credentials_id` or other credential-related tools. No when/when-not conditions or exclusions are given.

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