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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered; the description goes further with cost ("Free"), pagination behavior ("a page at a time"), the exact return payload (ownerId, voiceId, description, preview URL), and an unusual domain risk: whether a voice's maker must give notice before withdrawing it, which matters for recurring characters. That is substantive context an agent could not infer from the annotations or schema.

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?

Scope and facets are front-loaded, and the sentence about what each result includes earns its length because there is no output schema. The prose is a single sprawling sentence with stacked parentheticals, though, so an agent parsing quickly has to work harder than necessary to separate filters from return values.

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?

With nine optional parameters and no output schema, the description does the heavy lifting well: it explains filters, ordering, paging, result contents, cost and the stability flag. Gaps remain on the dangling "project" parameter, page size, and what an empty result looks like, but nothing essential to calling the tool correctly is absent.

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 every one of the nine parameters is already documented at the field level, and the description's enumeration of filters and sort orders largely restates that. It adds no syntax or edge-case guidance beyond the schema, and the optional "project" parameter is not mentioned at all. Baseline 3 applies.

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?

"Searches ElevenLabs' shared voice library" gives a specific verb and resource, and the qualifying clause ("the voices any project can keep without using one of its own") separates it from the account's own voices, i.e. from voices_read. The filtering, sorting and paging facets are named up front so the agent knows the tool's full scope before 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?

It makes the selection condition fairly clear: use this when you want a shared library voice rather than one the project already owns, and it names voice_keep as the natural next step by saying the results carry "what voice_keep takes." It stops short of explicitly telling the agent to prefer voices_read for its own voices or when to use voice_clone instead, so no hard exclusions are stated.

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