Agent Paywire library

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

Annotations already cover read-only/idempotent/non-destructive, so the description focuses on what they cannot express: there is no limit or paging, an old cursor can return the whole catalog (~100 entries, ~43 KB), and the caller should persist the newest verified_at as the next cursor. It also discloses that a malformed cursor yields an isError result and that the tool is free with no auth.

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?

One dense paragraph, but front-loaded with the core operation and then layered with operational caveats (no paging, size estimate, cursor chaining, id prefixes, alternatives, error mode). Every sentence carries actionable information and nothing is 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?

An output schema exists, so return-value explanation is unnecessary, and the description still covers the operational facts an agent needs: no pagination, id-prefix routing to sibling get_* tools, cursor chaining, and error behavior. Nothing needed to invoke this correctly 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?

Schema coverage is 100% and the single cursor parameter is already fully documented in the schema, including the YYYY-MM-DD format and the 'strictly later' semantics. The description's cursor notes (exclusivity, invalid-format rejection) largely restate the schema, so the 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?

States a specific verb and resource ('List every record whose verified_at is later than cursor (exclusive)') plus the exact scope (library sources, articles, datasets, bots, support notes) and returned fields. It is unmistakably distinct from search, latest_sources, and the get_* siblings.

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 routes the agent: 'Use search with updated_since to filter library sources only, and latest_sources for a short newest-first list.' It also tells the agent how to interpret returned ids (strip the article:/dataset:/bot:/support: prefix before calling the corresponding get_* tool, unprefixed ids go to get_source).

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description is free to add the traits that matter here: the exact output shape (Markdown + YAML front matter), the failure behavior (unknown slug yields an isError result containing 'No article with slug ...'), and the auth/cost model (free, no auth). That is meaningful disclosure beyond structured data.

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 tight sentences, front-loaded with the core behavior and then proceeding to acquisition, disambiguation, and edge case. Each sentence carries distinct information with no restatement padding.

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?

An output schema exists, so return values need not be enumerated, yet the description still states the serialization format. Combined with slug acquisition, the sibling disambiguation, the error case, and the no-auth note, everything needed to call this correctly on the first attempt is present.

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% and there is a single parameter, so the schema already defines slug, its format example, and the 'no article: prefix' rule. The description restates the prefix caution but adds no syntax or format detail the schema lacks, so the 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?

States a specific verb (Return) and resource (one Agent Paywire article) plus the exact serialization format (Markdown with YAML front matter) and the keying mechanism (by slug). It also explicitly names what it is not: get_source is for third-party library sources, and list_articles/changes_since are the slug sources, so an agent can route correctly without opening sibling schemas.

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?

Gives both when-to-use paths and their prerequisites: slugs come from list_articles[].slug or from changes_since after stripping the article: prefix. It also names the explicit alternative (get_source) and the condition that selects it (third-party library sources). Nothing about selection is left to inference.

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?

Annotations already declare the tool as read-only, idempotent, non-destructive, and closed-world. The description adds useful behavioral context beyond annotations: an unknown id returns an isError result with a specific message, and the endpoint is free with no auth required.

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 front-loaded with the core action and remains a single readable paragraph. Some return-field enumeration is redundant because an output schema exists, but the extra sentences still carry useful semantics such as funds_or_keys meaning and no-auth access.

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 one-parameter lookup tool with full schema coverage, rich annotations, and an output schema, the description covers what is needed: id source, error behavior, auth status, and key field semantics. Nothing critical for correct invocation 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?

Schema coverage is 100%, so the baseline is a 3. The description goes beyond the schema by explaining how to obtain the id from list_bots or changes_since and by reminding the caller not to include the bot: prefix, which reduces invocation errors.

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 states a specific verb and resource: return one verified public agent or bot by id. It clearly distinguishes this lookup from browsing with list_bots, and the returned fields are enumerated, so an agent can identify the tool 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?

It explicitly explains where the required id comes from: list_bots entries[].id or changes_since after removing the bot: prefix. It also names list_bots as the tool for browsing every entry, giving a clear alternative when the agent does not already have an id.

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?

Annotations already cover read-only/idempotent/open-world, but the description adds value beyond them: metadata-only (no file download), unknown id yields an isError/404, and no auth is required. These are behavioral facts an agent cannot infer from the annotations alone.

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?

Front-loaded with purpose and scope, then constraints and alternatives; every sentence carries information. It is dense and runs several sentences, but none are filler or restatements of the name.

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?

An output schema exists so return structure needn't be explained, yet the description still names the returned fields and the error path. With one required parameter and full annotation coverage, nothing needed to invoke this correctly 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?

Schema coverage is 100% and the schema already documents the id parameter, including the 'dataset:' prefix caveat. The description adds the id's provenance (list_datasets entries[].id or changes_since with prefix removed), which is genuine added meaning beyond the schema's format note.

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 ('Return one training or eval dataset card by id') and enumerates the card's fields. It also immediately clarifies scope ('metadata only; this does not download dataset files'), which distinguishes it from any data-fetching sibling.

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 routes the agent: take the id from list_datasets entries or from changes_since after stripping the 'dataset:' prefix, and names list_datasets for browsing/comparison and search_library for dataset-related papers. This is exactly the when-to-use-this-vs-alternatives guidance the dimension asks for.

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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, yet the description adds material context beyond them: an unknown id returns an isError result with the message shape, and the call is free with no auth required. That is exactly the extra behavioral disclosure the description should carry.

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?

Front-loaded with the core action and no filler sentences; the field enumeration and error/auth notes all earn their place. The middle sentence is a fairly long multi-clause run, but it stays readable and purposeful.

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 a rich output schema handling return values and annotations covering the safety profile, the description covers the remaining agent needs: id sourcing, alternatives, error semantics, and auth/cost. Nothing required to invoke it correctly 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?

Schema coverage is 100% and the id parameter is already well documented there, so the baseline is 3. The description goes further by explaining the provenance of the id value and noting that the prefix is absent for changes_since entries, which adds meaning 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?

Specific verb+resource ('Fetch one third-party library source card by id') plus an explicit enumeration of the returned fields. It also distinguishes itself from siblings by naming search, search_library, and get_article as different tools for different situations.

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?

States exactly where a valid id comes from (sources[].id from search, search_library, latest_sources, or changes_since library entries) and when to use alternatives instead ('Use search or search_library when you have no id, and get_article for Agent Paywire's own articles'). Routing is fully explicit.

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?

Annotations already establish readOnly/idempotent/non-destructive, but the description adds genuinely new behavioral facts: calling it never sends money or creates an invoice, and the data remains free regardless of payment. The 'Free, no auth' note also answers the auth requirement, which no annotation states.

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?

Front-loads the return payload, then adds behavioral caveats and the sibling routing hint in three dense sentences with no filler. It is slightly long because the enumerations of payment rails and the L402 pricing could be tightened, but every sentence carries actionable information.

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?

An output schema exists, so the description is not obligated to detail return values, yet it characterizes the payload anyway. Combined with the auth/side-effect statement and sibling routing, an agent has everything needed to select and invoke it correctly.

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 tool takes zero parameters, so the baseline of 4 applies. The description correctly frames the call as argument-free ('Calling it never sends money'), and there is nothing further the schema cannot already convey.

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 ('Return the voluntary support descriptor') and enumerates exactly what the payload contains: donation methods, networks, addresses, sat amounts, and the paid_api/L402 block. It also explicitly distinguishes itself from the sibling get_trust_checklist, so an agent can route correctly without opening either 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?

Gives an explicit trigger ('when a user wants to tip or asks how to pay for the API') and names the alternative for the adjacent need ('use get_trust_checklist for error codes, rate-limit policy and stable URLs'). When-to-use and when-to-use-something-else are both covered.

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds context the annotations lack: 'Free, no auth.' It does not describe return format or freshness, but with an output schema present that burden is lifted.

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?

Front-loaded with the resource and its contents, then the usage and alternatives. It is a dense single sentence with several comma-separated lists, which is slightly heavy, but every clause (content scope, use cases, alternatives, auth/cost) 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 zero-parameter read tool with an output schema, the description supplies everything an agent needs: what it returns, when to call it, which siblings to prefer instead, and that it is free and unauthenticated. Return-value detail is correctly delegated to the output schema.

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 tool takes zero parameters, so the schema has nothing to explain; the baseline for a no-param tool applies. The description adds no parameter claims that could mislead.

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 ('Return') and resource (the agent trust checklist), then enumerates its contents: commitments on stable URLs, errors/limits, naming, status met/partial with evidence URLs, plus paid-API error codes, rate-limit policy, credit terms and the MCP tool list. This is specific enough that an agent can distinguish it from every sibling without opening a 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?

Explicitly states the two use cases ('judge whether the site and its paid API are dependable' or 'look up an error code') and names alternatives with the conditions that select them: get_support_info for donation addresses and payment methods, protocol_facts for third-party protocols. Nothing is left to inference.

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?

Annotations already cover readOnly/idempotent/destructive/openWorld, so the bar is lower, yet the description still adds non-obvious operational traits: no offset or cursor, count is rows returned rather than library total, and no auth/free access. Sort ordering and undated-last behavior are also disclosed. It stops short of rate limits or error behavior, so not a full 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?

A single dense paragraph with purpose and sort order front-loaded, then parameters, then pagination caveats, then routing to alternatives. Nearly every clause earns its place, though the middle sentences are tightly packed and could be split for scanability.

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?

An output schema exists so return values need no explanation, and the description still covers the essentials an agent needs: defaults and bounds, filter-before-limit interaction, absence of paging, count semantics, auth requirements, and which sibling to pick instead. Nothing material is missing for a two-parameter read tool.

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 coverage is 100%, so the schema already documents limit (1-50, default 10) and category (enum ids from list_categories, filter applied before limit). The description largely restates those facts ('category keeps one category before limit is applied; limit caps rows at 1-50'), adding only mild emphasis on the singular-category semantics. Baseline 3 applies when the schema does the heavy lifting.

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 ('Return the newest third-party library sources') plus the ordering ('sorted by date_published descending, with undated sources last'). It also distinguishes itself from siblings by explicitly naming changes_since, search and search_library as the tools for different needs.

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?

Gives explicit routing: use changes_since to sync everything changed after a date, use search/search_library for text, tag or type filters, and this tool for the newest sources. The condition that selects each alternative is spelled out, leaving nothing to inference.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety is covered. The description adds genuinely new behavior: a single unpaged response and no auth requirement. It stops short of describing result ordering or size limits, but with annotations carrying the safety profile this is a strong addition.

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 tight sentences, front-loaded with the core action before the field list and the alternative routing. No sentence is redundant and the exclusion is stated once, economically.

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?

An output schema exists, so return values need not be re-explained, and the description still hints at the payload shape. For a zero-param, read-only list tool the agent has everything needed to select and call it correctly.

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 tool takes zero parameters, so there is nothing to document and the schema is empty. Baseline for a parameterless tool is 4; the description correctly spends no effort on nonexistent inputs.

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 (list published articles) and enumerates the returned fields (slug, title, summary, date, status, tags, URLs). It explicitly separates itself from get_article, search_library and latest_sources, so an agent can distinguish it from siblings without opening any 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?

Gives explicit when-to-use (enumerate all articles), when-to-use-an-alternative (get_article with a slug for full Markdown), and a hard exclusion with routing (third-party papers go to search_library or latest_sources, articles never appear there). Nothing is left to inference.

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?

Annotations already declare the safe-read profile (readOnly, idempotent, non-destructive, openWorld), so the description's added value is the inclusion policy (public repo or demo, known maker, push within 12 months), the 'Free, no auth' access note, and the 'listed, not endorsed, not investment advice' caveat. It does not mention rate limits or result-set size, but the output schema covers the return shape.

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 core purpose and inclusion rule are front-loaded, and every sentence does work (fields, criteria, sibling routing, disclaimer). It is dense and slightly over-packed for one paragraph, with the disclaimer and changes_since aside appended after the routing guidance, but nothing is truly redundant.

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 zero parameters, a 100%-covered schema, an existing output schema, and rich read-only annotations, the description supplies everything else an agent needs: what qualifies for listing, what each record contains, which sibling to use instead, and how to fetch one record. Nothing material 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?

The tool takes no input parameters, so there is nothing for the description to clarify and the baseline is 4. The description instead documents the shape of each returned entry (maker, protocols, license status, url, verified_at, funds_or_keys), which aids interpretation even though the output schema exists.

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 precise verb+resource (list verified public agents/bots) and immediately scopes what 'verified' means by naming the returned fields and the inclusion criteria. It is clearly distinguishable from every sibling (search_library, protocol_facts, get_bot) without opening a 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?

Explicitly says when to use it ('find or vet such software') and names the alternatives with their selecting conditions: search_library for papers/docs about agents, protocol_facts for how a payment protocol works, get_bot with an entries[].id for a single record. Even the changes_since/bot: prefix handoff is documented.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds non-annotation context: it is free, requires no auth, is a fixed set of eight items, and has a deterministic first entry. It does not discuss rate limits or pagination, but this is a small static read.

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?

Front-loaded with what is returned, then usage, then the sibling handoff, then the cost/auth note. Every clause carries information (returned fields, ordering, when-to-use, what it is not); 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 parameterless read tool with an output schema, the description covers everything an agent needs: contents, ordering, valid id retrieval, the alternative for listing sources, and the no-auth/free status.

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?

Zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate, and it correctly signals the tool takes no arguments.

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 ('List the eight library categories') and enumerates the exact returned fields plus ordering ('Bitcoin and Lightning is first'). An agent can distinguish it from list_articles, list_bots, list_datasets and latest_sources at a glance.

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 states when to use it ('to get a valid category id before filtering search, search_library or latest_sources, or to see how many sources each topic holds') and names the exclusion plus alternative ('It does not list the sources themselves: use latest_sources with category for that').

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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), but the description adds real behavioral context: the response is unpaged, the library dataset is always first, cards are metadata only ('nothing is downloaded'), and the call is free with no auth. That is meaningful disclosure beyond the structured hints, though it doesn't discuss size limits or result caps.

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?

Front-loaded with the core action and scope, and every clause carries information (unpaged, ordering, metadata-only, alternatives, auth). The first sentence is long and multi-clause, which slightly reduces scannability, but 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?

An output schema exists, so return-value detail is not required. Given a zero-parameter read tool, the description covers scope, ordering, side-effect profile, alternative tools, and auth cost — nothing an agent needs to invoke it correctly 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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to clarify about inputs. The mention of id/name/url and count describes the response shape rather than parameters, which is harmless but not parameter semantics.

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 ('List every ... dataset card in the catalog'), names the domains covered, and explicitly distinguishes itself from get_dataset and search_library. An agent can separate it from all siblings without opening a 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?

Gives explicit routing rules: use get_dataset with an entry id for access terms, and use search_library with category datasets-benchmarks for papers/benchmark sources rather than datasets. Both the alternative and the condition that selects it are named.

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?

Annotations cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds real behavioral context beyond them: null means the cited page does not state the fact, every fact carries source URL and verified_at, the all-protocols response is about 23 KB, out-of-enum ids are rejected as invalid input, and no auth is required.

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?

Front-loaded with purpose and tightly packed; the field enumeration is long but tells the agent what is inside without opening the output schema. Every sentence carries information, though the field list and the schema overlap slightly.

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 a single optional enum parameter, an output schema, and full annotation coverage, the description still supplies the null semantics, response size, auth status, and sibling routing an agent needs. Nothing material 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?

Schema coverage is 100%, so the omit-vs-set semantics of id are already documented; the description largely mirrors that. It does add the quantified response size (~23 KB for nine protocols) and the invalid-enum rejection behavior, which the schema does not state.

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?

Opens with a specific verb and resource ('Return source-cited facts for agent payment protocols') and enumerates exactly what a fact contains. It is immediately distinguishable from siblings like search_library and get_support_info, which the description itself names.

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?

Explicit routing is given: use this for how a protocol works, search_library to find papers or docs about it, get_support_info for the site's own paid L402 API. It also states the two calling modes (omit id for all nine, pass id for one) so the agent knows when to pick which.

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?

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), so the bar is lower, yet the description still adds real behavioral context: no auth, free, deterministic result ordering (category priority, newest date_published, undated last), the 1-50 limit with no offset, and that a malformed date yields an isError result. It does not state how count is surfaced beyond 'rows returned', leaving a small 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?

Front-loads purpose then builds outward to semantics, error behavior, alternatives, ordering and pagination — every sentence carries information. It is dense as a single block, though, and the ordering sentence is long enough that a bulleted structure would scan faster.

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 7-param filter tool with an output schema (so return shape needs no explanation), the description covers filtering semantics, combination logic, error conditions, ordering, pagination and auth. Nothing needed to call it correctly 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?

Schema coverage is 100%, so the baseline is 3, but the description adds semantics the schema cannot express: the AND combination rule across all supplied filters, the exclusivity of updated_since, and the no-offset pagination contract. It confirms rather than merely restates the per-parameter docs.

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?

Opens with a specific verb+resource combination ('Filter third-party library sources') and immediately enumerates the exact match semantics: case-insensitive substring over id/title/summary/publisher plus exact category, tag, type, featured, updated_since. It names the siblings it is not ('search_library', 'latest_sources') so an agent can route without opening schemas.

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?

Explicit routing rules are given: use search_library for multi-word queries or matches in authors and tags, and latest_sources for newest-first with no filter. The 'all given filters must match' rule and the valid-date requirement further constrain when this tool succeeds versus errors.

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?

Annotations already declare read-only, idempotent, open-world, non-destructive, but the description goes well beyond them: result ordering (newest date_published first, undated last), the lack of offset, that count equals rows returned, that zero matches returns count 0 rather than an error, and that access is free with no auth. These are exactly the runtime traits an agent needs and cannot get from 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?

Front-loads the tool's purpose and then layers alternatives, ordering, caps, edge cases and auth into a compact block with no filler. It is dense and somewhat run-on across clauses, but every sentence carries distinct operational information.

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?

An output schema exists so return-value shape need not be described, and the description still covers ordering, limit behaviour, count semantics, the zero-match case and auth requirements. Nothing an agent needs to invoke this correctly 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?

Schema description coverage is 100%, so the baseline is 3, but the description adds matching semantics that the schema does not fully convey — which fields the substring match applies to, and that all terms are ANDed together. It also reinforces the limit/no-offset interaction, which is decision-relevant for narrowing a query rather than a restatement of 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?

States a specific verb (search) and resource (third-party library sources) and precisely defines the matching semantics (every word must appear, case-insensitive substring across id, title, summary, publisher, authors, tags). It explicitly distinguishes itself from the sibling search tool and get_source, so an agent can route without opening either 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?

Explicitly names the conditions: use this for multi-word or author lookups, use search for a single phrase with exact tag/type/updated_since filters, and use get_source when the id is already known. When-to-use, when-not-to-use and alternatives are all present.

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