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

Annotations already cover read-only and open-world nature, but the description adds substantial behavioral context beyond them: the exact returned field set, explicitly excluded data, a per-call price of $0.002 USDC, the x402 payment rails (Base, Solana, Arc), and the fact that failed calls are not charged. That failure-charging note is genuinely decision-relevant. It does not explain wallet/auth setup for x402 or any rate limits, which keeps it 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?

Purpose is front-loaded and the returned-fields enumeration earns its space, but the related-tools sentence is bloated and grammatically broken ('from Pinterest's;', 'from the video page's.'), reading as truncated boilerplate. The pricing sentence is long and could be tightened without losing information.

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 only one parameter, an output schema present, and annotations supplied, the description covers what an agent needs: what it returns, what it will not return, and what it costs. The main remaining gap is practical access detail for a paid x402 endpoint (wallet/credential expectations), which the description gestures at but never explains.

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?

There is a single required parameter and schema coverage is 100%, with the schema itself specifying the format constraint (3-15 chars, letters/digits/._-, no @). The description adds no syntax or validation meaning beyond that, so the baseline 3 for well-covered schemas applies.

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?

States a specific resource (public Snapchat profile scraped from its web profile page) and enumerates the returned fields: username, display name, page title/description, snapcode image, canonical link. It even declares what is absent (stories, Spotlight, follower counts). It loses a point on sibling differentiation: the named relatives are social_pinterest and social_tiktok, which are far less confusable than social_tiktok_profile or social_instagram_profile, which go unmentioned.

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?

Gives a clear negative boundary ('Stories, Spotlight posts and follower counts ... are not returned') which tells the agent when this tool will not satisfy a request, and it names alternative tools with a 'when you need' condition. However, the alternatives are framed around Pinterest pins and a single TikTok video rather than other profile-lookup tools, so the routing is of limited practical use for the most likely confusion.

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