pinterest_get_business_assets

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

With no annotations, the description carries the behavioral burden. The verb 'Read' clearly signals a non-mutating operation, and the permission requirement plus the enumerated response categories add useful context. However, it does not disclose pagination, error behavior, rate limits, or how the response is structured for the various modes.

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 one sentence, front-loaded with the action and resource, and contains no filler. The long comma-separated list is dense but each item contributes to the scope. It could be broken into clearer clauses, so it is concise but not perfectly structured.

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 tool with 11 parameters, no output schema, and no annotations, this description is too thin to fully orient an agent. It establishes the general intent and permission requirement but does not clarify how mode drives the request, what query parameter to use, or what the returned inventory looks like. The schema fills some gaps, but a complex tool like this needs more operational context.

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?

With only 36% schema description coverage and 11 parameters, the description needed to compensate but does not. The category list loosely maps to the mode enum values, adding some conceptual grouping, but it does not explain query, adAccountId, allowCrossBusinessRead, includePersonalIdentifiers, or other parameters. The schema already provides the mode enum, so the description mostly repeats rather than enriches it.

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 uses a specific verb ('Read') and names a clear resource ('Pinterest Business Access inventory'), then lists the scopes: employers/linked businesses, assets, members, partners, assigned assets, received audiences, and invites. However, it does not differentiate this from sibling tools like pinterest_get_account_entitities or pinterest_get_audiences, so it falls short of a full 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?

The description gives a prerequisite ('requires the corresponding business-management permissions') but does not explain when to choose this tool over alternatives. It neither names a sibling nor specifies exclusions, leaving the agent to infer appropriate use from the resource name alone.

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