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

readOnlyHint=true already tells the agent this is a safe read, but the description adds a genuinely surprising behavioral trait — only immediate campaigns are returned — plus the paged-collection nature and the underlying REST endpoint. It does not disclose default page size, response shape, or rate limits, so it stops short of a 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?

Two tight sentences with the scope stated first, the caveat second, and an endpoint mapping appended. No sentence is padding; the caveat is appropriately prominent.

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 seven-parameter, fully optional, read-only list tool, the description covers filtering, pagination semantics, and the key content exclusion. With no output schema, it could say slightly more about what each returned record contains or the default page size, but nothing critical for correct invocation 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 seven parameters are already documented in the schema. The description restates the filter categories (sending number, state, list, date range) without adding format syntax, date formats, or precedence rules, so it earns the baseline 3 rather than more.

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 gives a specific verb ('List') and resource ('the account's campaigns') and specifies the scope as a 'paged collection', which reads as the bulk-listing tool. It does not name any sibling tool, so the differentiation from simpletexting_get_campaign is left to be inferred from the plural/resource framing.

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 states the available filter dimensions (sending number, state, list, start-date range) and adds an explicit exclusion: scheduled/recurring campaigns are NOT returned. That exclusion functions as useful when-not guidance, but no alternative tool is named for retrieving scheduled/recurring campaigns or a single campaign.

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