stubhub_carousel

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

With no annotations, the description correctly carries the burden: it states the tool is a listing operation, names the returned sections, and discloses browser impersonation plus the absence of cookie/CSRF requirements. It does not cover rate limits, pagination, or failure behavior, but for a read-only carousel fetch the essential behavioral traits are disclosed.

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?

Three sentences with no filler: action and scope, returned sections, then parameter sourcing and auth behavior. The description is front-loaded with the core purpose and every sentence earns its place.

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 tool with no output schema and six required parameters, the description covers what the return contains, how to source two key parameters, and the auth profile. It is slightly incomplete about how top_level_category_id, category_id, lat, and lon affect results, but the schema covers their basic meaning, so the description is broadly sufficient.

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 documents all 7 parameters with descriptions, so the baseline is 3. The description adds extra semantic value by telling the agent where performer_slug and performer_id come from, which is more than the schema offers. It does not explain how category and location parameters shape the results, but those are adequately covered by the schema descriptions.

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 first sentence names a specific verb ("List"), a specific resource ("StubHub performer discovery carousels"), and enumerates the carousel sections, so an agent knows what the tool returns. It is clear, but it does not contrast with sibling tools such as stubhub_performer_events or stubhub_explore, so it falls just short of a 5.

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 useful context for invoking it—source performer_slug and performer_id from a real performer URL or another StubHub result—and notes that no cookies or CSRF state are needed. It never states when to choose this over sibling StubHub tools or when not to use it, so usage guidance remains implied rather than explicit.

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