sportsbet_match_preview

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

Annotations already establish read-only, idempotent, open-world behavior. The description adds a concrete return envelope ({preview:{itle, body, videoUrl}) and an auth nuance: no key required, with SPORTSBET_REFRESH_TOKEN unlocking more. That is useful behavioral context, though 'more' is vague.

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 short sentences cover purpose, return shape, and auth, with the central purpose front-loaded. Every sentence contributes information and there is no filler.

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 read-only preview tool with four clearly described parameters and annotations, the description includes the return shape and auth requirements. It would be slightly more complete if it explained what the optional token unlocks or noted the behavior when no preview exists, but nothing required to call it 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?

All four parameters have schema descriptions (100% coverage), so the baseline applies; the description does not restate parameter formats or value semantics. The Returns line hints at what the parameters are used for but adds no detail beyond the schema.

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 opening sentence specifies an action (preview), resource (one sport event), and content type (editorial text + video). 'Match' clearly separates it from racing-focused siblings like sportsbet_race_preview, so an agent can identify it without opening the schema.

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 implies when the tool is relevant—when editorial preview content for a match is needed—but it does not state alternatives, exclusions, or when to prefer another sportsbet content tool such as event_commentary or sports_card. This is adequate implied guidance, not explicit routing.

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