Get an X profile

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

Annotations already cover readOnlyHint, openWorldHint, idempotentHint, destructiveHint, so the description does not need to reintroduce those. It adds valuable behavioral context beyond the annotations: the tool returns only public profile data, its 404 error maps to absent/suspended/private accounts, and it clarifies that the standalone return is not posts. This is genuinely useful, though it does not address rate limits or auth requirements, so a 4 is appropriate rather than 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?

The description is front-loaded with the one-line definition, then provides pragmatic 'Use this to' bullets, alternative routing, and structured sections for parameters, return format, and errors. The repetition of the field list in the intro and in the Returns section is intentional to give both a quick overview and explicit per-format details. It is long, but every section earns its place by answering the likely questions an agent has when selecting and invoking this tool.

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 two parameters and no output schema, the description fully compensates by explaining the return shape for both markdown and json formats (listing all fields and key names), error semantics, and input variations. It also distinguishes this tool from all relevant siblings and states exclusions. An agent has everything needed to call this tool correctly without inspecting nested schemas or additional documentation.

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 coverage is 100% and both parameters are well-described in the schema. The description still adds meaning beyond the schema: handle accepts 'jack', '@jack', or full URL, and warns that display names won't work while noting handles are 1-15 letters/digits/underscores. For format, it reinforces the token-cost distinction between markdown and json. This goes beyond simply repeating the schema, but much of the ground is already covered, justifying a 4.

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-resource pair ('Fetch a public X/Twitter profile by handle') and enumerates exactly what fields are returned (display name, bio, location, website, join date, verification status, avatar and banner URLs, counts). It differentiates itself from siblings by explicitly stating 'It returns the profile only — not the account's posts', making its scope unmistakable.

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 direct use cases: 'Use this to answer "who is @x", to check whether an account exists, or to get follower counts.' It goes further to 'When to use this instead of the alternatives' and names both xcrap_get_user_tweets and xcrap_get_tweet with conditions for each. It also excludes the wrong use case: 'It returns the profile only — not the account's posts.'

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