twitter_community_about

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. It adds behavioral context by specifying that it returns 'FULL user profiles' with detailed fields, which goes beyond the schema. It also clarifies the endpoint is about people, not the community object, adding useful nuance beyond what annotations convey. No contradictions with annotations.

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 two sentences, tightly written, and front-loaded with the core purpose. Every clause adds value: it states what it returns, contrasts with reduced-row siblings, and directs to the correct alternative for metadata. No fluff or redundancy.

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 simple single-parameter tool with strong annotations and full schema coverage, the description provides complete context. It describes the output content (full profiles with specific fields), explains the differentiation from related tools, and clarifies the scope (people vs community object). No output schema exists, but the description sufficiently conveys what to expect. The tool's complexity is low, and nothing critical 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?

The schema description fully covers community_id with an example and URL context (100% coverage). The tool description does not add any extra parameter semantics, but the schema is sufficient. Baseline 3 applies because the parameter is already well-documented; the description does not need to repeat 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 clearly states the tool's function: returning full user profiles for a community's moderators and a preview of its members. It names the specific fields included and explicitly distinguishes it from sibling tools like twitter_community_members and twitter_community_moderators, which return reduced rows, and twitter_community_info, which covers community metadata. This makes the purpose unambiguous and easily differentiated.

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 provides explicit when-to-use guidance and names alternatives: it says to use this tool when full profiles are needed versus reduced rows from twitter_community_members/moderators, and directs users to twitter_community_info for community metadata. It also explains that this endpoint answers 'who runs a community' in one call, covering when and why to choose it.

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