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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely new behavior: calls cost no Adrails credits, and UI reports/questions come back as structured content. It does not describe response shape or how freshness is expressed, which keeps it below 5.

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 capability statement and the "read this before" guidance are front-loaded and earn their place, and the concrete example answers are useful. However, the trailing block is boilerplate, and "MCP: use the input object for tool arguments" is actively confusing given the required input object has no properties.

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 carries the burden of explaining return values; it gestures at them (per-source capabilities, per-stream freshness) but never states the shape. Sibling differentiation against integrations_catalog and integrations_detail is also absent. It is enough to know when to call it, but not enough to predict what comes back.

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 75%, so the schema already documents accountIds, userStatement and idempotencyKey. The description says nothing about any parameter, leaving the required but property-less "input" object unexplained and offering no hint that accountIds can only narrow access. 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 resource and its facets: what is connected, what each source can do, and per-stream freshness. That is more than a restatement of the name. It does not distinguish itself from the sibling tools integrations_catalog and integrations_detail, so an agent cannot tell from the description alone which of the three to open.

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 an explicit trigger — "Read this before saying a figure is missing" — and illustrates the shape of a good answer ("connect Shopify", "the order sync has been failing since Tuesday"). It stops short of naming alternatives or when-not-to-use, notably the integrations_catalog and integrations_detail siblings, 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.