sportsbet_graphql_call

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

With no annotations provided, the description must fully disclose behavioral traits. It mentions that hashes are server-managed and describes a specific error scenario. However, it does not explicitly state whether the operation has side effects (likely read-only), authentication requirements, rate limits, or other important behaviors. The disclosure is adequate but not comprehensive.

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 concise, with three sentences that are front-loaded: first sentence states the core purpose, second provides error handling and reference, third specifies return type. Every sentence earns its place with no 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?

Given the tool's complexity as a generic GraphQL call with no output schema and 0% schema coverage, the description provides necessary context by directing to an external resource for operations and variable signatures. It lacks details on common operations, authentication, or error codes beyond the one mentioned, but this is largely acceptable due to the external reference.

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 description adds minimal meaning beyond the input schema: it refers to parameters as 'name + variables' and directs to an external source for variable signatures. With 0% schema description coverage, the description partially compensates but does not provide sufficient detail about parameter formats, constraints, or examples.

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 purpose: calling any of Sportsbet's persisted GraphQL operations by name and variables, specifying the exact endpoint URL. It distinguishes from sibling tools which are mostly specific data endpoints (e.g., sportsbet_racecard) by being a generic call interface.

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 guidance on when to use this tool (for persisted operations not covered by specific tools) and mentions error handling (PERSISTED_QUERY_NOT_FOUND indicates bundle drift). It also directs the user to an external resource (sportsbet://graphql/operations) for the operation list and variable signatures, which is essential for correct usage.

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