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

The annotations already declare readOnly=true, idempotent=true, openWorld=true, and destructive=false, so the safety profile is covered. The description adds context that the annotations do not provide: the price of ¥0.1 per call, that billing applies only to successful calls, and that failed or empty results are automatically refunded. This is meaningful behavioral context for a paid API, though it does not cover rate limits or error 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?

Four sentences, each with a job: what it does, what it returns, when to use it, and what it costs. The purpose comes first and there is no filler or repetition.

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 usefully lists the return payload (text, engagement counts, author, media, timestamp). It also discloses billing semantics, which is important for a metered call. Only the ID format, the behavior when the tweet is deleted, and any rate limits remain unstated.

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%, with both tweet_id (required) and the fallback _token documented in the schema. For tweet_id, the description adds no format, ID-type, or URL-to-ID conversion guidance beyond what the input schema says. With the schema already doing the work, the baseline of 3 is appropriate.

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 verb and resource ('获取推文详情') and immediately enumerates what comes back: text body, like/retweet/reply/quote counts, author info, media, and publish time. That implicitly separates it from helpers like tw_post_comments or tw_user_posts, but it never names a sibling explicitly, so it falls short of full 5-level differentiation.

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 concrete usage scenarios: single-item engagement analysis, asset/corpus ingestion, or as the entry point for a batch task. This tells the agent when to reach for it, but it never names exclusions or the alternative tools to use instead, so the agent has to infer that comment threads and user timelines belong to different tools.

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