Get a Bopster creator profile

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

With no annotations, the description carries the full burden. 'Fetch a public creator profile' implies a safe read, and listing the returned fields adds value, but it omits auth requirements, not-found behavior for invalid handles, and any rate-limit or pagination context.

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?

Two tight sentences that front-load the action and resource, then name the accepted input forms. Every sentence earns its place with no padding.

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 one-parameter read tool with no output schema, the description covers the returned fields and input options well. The main gap is failing to differentiate from get_user_profile and to say what happens when the handle is not found.

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%, so the handle parameter is already fully documented in the schema. The description merely restates that a wallet or alias is accepted and adds no new format, validation, or example detail beyond what the schema says.

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 ('Fetch a public creator profile on Bopster') and names the returned fields (alias, avatar, verified badge, creator stats). It does not distinguish itself from the sibling get_user_profile, leaving an agent to infer which profile tool to use.

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?

It implies a read-only lookup and notes that either a wallet address or alias is accepted, but gives no explicit when-to-use or when-not-to-use guidance and does not mention the get_user_profile alternative. Usage is inferable but not directed.

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