get_ftso_providers

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

No annotations are present, so the description carries the full behavioral disclosure burden. It only says 'get the list of active providers' and does not disclose pagination behavior, ordering, limit effects, reward epoch semantics, or return format details. The word 'active' adds some filtering context, but most behavioral information is left implicit.

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 a single front-loaded sentence with no filler. It efficiently conveys the resource, scope, and output fields, making it concise while still adding useful information given the absence of an output schema.

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?

The description captures the core purpose and output fields, which is enough for an agent to attempt a call. However, with no annotations and no output schema, it should also clarify limit behavior, reward epoch selection, and any pagination or ordering expectations. These gaps make it minimally viable but not complete.

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 only 33%, and the description adds minimal parameter meaning beyond confirming the network context. It does not explain the limit parameter semantics, the maximum/default behavior, or reward_epoch_id beyond what the schema already states. With low coverage, the description needed to compensate but largely did not.

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, 'Get', and identifies the exact resource: 'active FTSO data providers'. It also lists the returned fields (name, address, vote power, fee, reward rate), making the tool's purpose unmistakable and clearly distinct from sibling feed/history tools.

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 clear context by requiring a network and targeting provider data rather than feed data. However, it does not explicitly state when to prefer this tool over siblings like get_ftso_feeds_all or get_ftso_history, and it provides no exclusions or alternative routing.

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