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

No annotations are present, so the description carries full responsibility—and it delivers: discloses short-lived session-bound links, no caching/reuse, daily allowance consumption, and the server's inability to save files unless an env var is set. This is exceptional behavioral disclosure for a tool with zero annotations.

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?

Four sentences, each earning its place, with the primary action stated first. Slightly long due to the environment variable note, but no redundant 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?

Covers input provenance, link lifetime, usage constraint, allowance impact, and prerequisite server configuration. Missing explicit error behavior or response shape details, but the tool's output is simple (a URL) and no output schema exists.

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%, with both book_id and hash already described, including the 'must match' relationship. The description reiterates that they come from a zlib_search result but adds no new semantic detail beyond what the schema already provides.

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?

States a specific verb and resource ('Get a direct download URL for one book') and identifies the required inputs (id and hash from zlib_search). This clearly differentiates it from siblings like zlib_search, zlib_limits, and zlib_login.

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?

Clearly indicates when it should be used: after obtaining a zlib_search result, and warns to use the link immediately without caching or reuse. It also notes the allowance consumption and points to zlib_limits, though it doesn't explicitly state when not to use it.

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

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

With no annotations provided, the description carries the burden, and it does well by stating that 'does not consume any allowance'—a key safety guarantee for a quota-check operation. It also implies the output fields (used, cap, remaining). It doesn't mention authentication requirements or error behavior if not logged in, which is a minor gap.

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?

Two sentences deliver the core purpose, usage triggers, and side-effect profile without any filler. The most important information (what it checks) is front-loaded, followed by when to use it and the safety guarantee—every clause 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 simple zero-parameter tool without an output schema, this description is quite complete: it lists the returned values (used, cap, remain) and when to call it. The main omission is whether authentication is required before calling, given the account-specific nature and the existence of zlib_login as a sibling.

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 input schema is empty with 100% coverage, so there are no parameters to describe. The description redundantly notes 'Takes no arguments,' which adds no semantic value but does confirm the expectation. A baseline of 4 is appropriate for zero-parameter tools.

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 ('Check') and clearly identifies the resource: the z-library account's daily download allowance. It details exactly what information is provided (used today, daily cap, remaining), which sets it apart from the sibling tools focused on searching, downloading, or logging in.

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 explicitly says when to call the tool: before a batch of downloads, or when a download fails with a quota error. It doesn't mention when not to use it or point to alternatives, but given there are no sibling tools that check quotas, the guidance is clear and sufficient.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses that the password is never stored, logged, or returned, that the returned credentials are long-lived, and that the server must be restarted. This goes well beyond the 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?

Every sentence earns its place: operation, lifecycle context, security disclosure, and anti-misuse warning. It is front-loaded with the core purpose and avoids 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?

Despite having no output schema and no annotations, the description explains what the call returns, how to use the returned values, and the one-time nature of the operation. For a two-parameter setup tool, this is complete and actionable.

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 input schema already documents both parameters fully, so the baseline is 3. The description clarifies the overall purpose of email/password and the long-lived credentials, but adds no additional format or constraint semantics for the parameters themselves.

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?

States a specific action and resource: 'Exchange a z-library email + password for the long-lived remix credentials (remix_id / remix_key).' It clearly distinguishes itself from the sibling search/download/limit tools by positioning as a one-time setup helper rather than a per-call operation.

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?

Explicitly says when to use ('one-time setup helper'), when not to ('not a per-call login', 'Do not call this before every search'), and what to do after calling (configure ZLIB_REMIX_ID/ZLIB_REMIX_KEY and restart). This gives an agent a clear decision boundary.

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

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

With no annotations, the description carries the full burden and it does well: it says the result is a trimmed list, enumerates the fields each entry carries, and instructs not to download without user selection, implying a safe read-only search step. It does not mention pagination totals, error behavior, or auth requirements, which keeps it just below a 5.

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 two sentences with no waste: the first states the core action, the second adds the output shape and the required user-interaction step. It is front-loaded 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?

Given 8 parameters with full schema coverage and no output schema, the description compensates by explaining what the return entries contain and how they feed downstream tools. It is sufficient for correct invocation, though a note on pagination/total result behavior would make it fully 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 100%, so the schema already documents every parameter clearly. The description adds no extra parameter-level detail beyond the output relationship, so the baseline of 3 is appropriate.

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 action ('Search z-library for books') and the resource ('z-library'), and distinguishes the tool from siblings by explaining it returns a candidate list with the id/hash that zlib_get_download_url and zlib_download require. This makes the tool's role in the download workflow immediately clear.

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 explicitly tells the agent to present candidates to the user and let them pick before downloading anything, which defines when this tool should be used relative to the download siblings. It also names the downstream tools that consume its output, giving clear workflow placement.

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