New Mexico Literacy Project

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

Discloses data sources (Discogs-derived index plus MusicBrainz fallback) and links to human tool, which is useful. However, no annotations are provided, and the description does not mention rate limits, authentication, or side effects. The behavior is adequately described for a read-only lookup.

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 efficient sentences plus a URL. First sentence clearly states purpose and examples; second sentence explains backing. No redundant or unnecessary text.

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 no output schema, the description explicitly states returned fields (artist, album, year, label). The single parameter is fully specified. All necessary information for an agent to invoke correctly 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 coverage is 100%, baseline 3. The description adds concrete examples (DIDX-2113, CK 40999, D ######) beyond the schema description, helping the agent understand acceptable formats.

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 'Identify', resource 'CD', and lists several concrete identifier types (DIDX IDs, catalog numbers, barcodes, music-club numbers). The description clearly distinguishes this CD-focused tool from sibling tools like nmlp_vinyl_lookup or nmlp_lccn_lookup.

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 implies use for any CD identifier printed on the disc or packaging, but does not explicitly state when not to use or contrast with siblings. The context is clear enough for an agent to select it for CD queries.

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?

No annotations provided, so description bears full burden. Describes return fields (coverage tier, pickup window, min quantity, message) and implies it is a read-only check. Lacks mention of potential side effects, but likely none.

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: first explains purpose and output, second gives usage instruction. No wasted words, front-loaded with main purpose.

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 check tool with one parameter and no output schema, the description fully explains the return fields and usage context (prerequisite for scheduling). 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 coverage is 100% with a clear description and pattern for the 'zip' parameter. The description adds no additional meaning beyond what the schema provides, so baseline of 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?

Clearly states the verb 'check' and the resource 'coverage at a five-digit US ZIP code'. Distinguishes itself from the sibling 'nmlp_schedule_pickup' by explicitly stating it should be called before that tool.

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?

Provides explicit instruction to always call this before nmlp_schedule_pickup, indicating its role as a prerequisite. No explicit when-not-to-use, but the context is clear.

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 full burden. It discloses behavioral traits: handling the Random-House-ends-in-2 exception, flagging book-club editions, and returning three items (printing, verdict, detected line). This goes beyond basic purpose to inform the agent of edge cases and output structure.

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, front-loaded with the action verb 'Decode'. Every sentence adds information: first sentence states purpose and scope, second lists exceptions and outputs. No wasted words.

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 no output schema, the description fully explains the return values: 'the printing, a plain-English verdict, and the detected line.' It covers anomaly handling (Random-House-ends-in-2) and classification (book-club flags). For a single-parameter tool, this is complete and informative.

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% with a description already. The description adds value by providing an example ('10 9 8 7 6 5 4 3 2 1') and clarifying that it can include 'First Edition' wording. This helps the agent understand what to pass and the format.

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 action ('Decode a copyright-page number line / printer's key') and the specific purpose ('to determine which printing a book is'). It specifies the input and output, and distinguishes itself from siblings by mentioning specialized handling (Random-House-ends-in-2 exception, book-club edition flags).

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 tells when to use: when you have a number line and/or 'First Edition' wording. It provides clear context about what to paste. However, it does not explicitly mention when not to use or compare with alternatives (e.g., nmlp_identify_first_edition), which would enhance guidance.

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?

No annotations are provided, so the description must disclose behavioral traits. It only states the action and output format, but omits essential details like whether the operation is read-only, the scope of entries returned (all? recent?), or any pagination/limitations.

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 sentence that efficiently conveys the tool's purpose and output format. It is front-loaded and contains no extraneous 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?

With no parameters, no output schema, and no annotations, the description is the sole source of information. It fails to explain the scope of 'archive entries' (e.g., date range, completeness), the structure of a 'Book record,' or any constraints. This leaves the agent with significant ambiguity about the tool's behavior.

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 has zero parameters, and schema description coverage is 100% (vacuously). The description adds value by indicating the output is 'structured Book records,' which provides semantic context for what the agent can expect. Following the baseline of 4 for 0-parameter tools, this 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 tool retrieves 'donation archive entries' and formats them as 'structured Book records.' It is specific about the resource and output, and distinguishes itself from sibling tools that retrieve other types of data (e.g., business cards, donation options). However, it does not explicitly contrast with similar looking siblings like 'nmlp_get_knowledge' or 'nmlp_get_pillar_guides.'

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 no guidance on when to use this tool versus its siblings. It lacks context such as prerequisites, typical use cases, or conditions under which this tool is appropriate.

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?

No annotations are provided, so the description must carry the full burden. It only indicates a read operation ("get") and lists return fields. It does not disclose any potential side effects, auth requirements, or rate limits, leaving the agent with minimal behavioral context.

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, well-structured sentence that efficiently conveys the tool's purpose and return content. Every word adds value, achieving maximum conciseness.

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 has no parameters, no output schema, and no annotations, the description adequately covers what the tool returns. However, it could mention that the result is a single card (canonical) and hint at no side effects. Overall, it is sufficient for a simple retrieval 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?

The input schema is empty (0 parameters, 100% coverage), so the description need not explain parameters. The baseline for no parameters is 4, and the description appropriately reflects that no inputs are needed.

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 retrieves NMLP's canonical business entity card with specific fields (address, phone, services, area served, languages). This distinguishes it from sibling tools like nmlp_cd_lookup or nmlp_check_coverage, which serve different purposes.

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?

No guidance is given on when to use this tool versus alternatives. While the tool's simplicity reduces ambiguity, the presence of many sibling tools would benefit from explicit context on when to call get_business_card versus other lookups.

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?

No annotations are provided, so the description carries the burden. It states it returns a 'comparison matrix' and lists included options, but does not disclose any behavioral traits like authentication needs or output format. Adequate for a simple no-parameter tool.

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 concise sentence that is front-loaded with the action and resource. Every word adds value, 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?

For a simple tool with no parameters and no output schema, the description fully conveys the purpose and scope by listing all donation options. It is complete and self-contained.

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?

There are no parameters, so baseline 4 applies. The description does not need to add parameter info since the input schema is empty and coverage is 100%.

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 verb 'Get' and the resource 'comparison matrix of every Albuquerque book donation option', listing specific options. It distinguishes from sibling tools that focus on book identification, archives, etc.

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?

No explicit when-to-use or when-not-to-use guidance is provided. However, the description implies this tool is for comparing donation options, and given the sibling tool names, it is the only one relevant to donations.

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 full burden but only lists content categories. It does not disclose behavioral traits such as read-only nature, authentication needs, performance characteristics, or side effects.

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 sentence that is front-loaded with the action and lists contents. It is appropriately sized but slightly dense; could be split for better readability. No wasted words.

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 simplicity (no parameters, no output schema), the description provides adequate context by listing the knowledge base sections. It does not discuss return format or size, but for a simple read operation without parameters, it is largely 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?

The input schema is empty (0 parameters) and schema description coverage is 100%. The description adds value by enumerating the knowledge base contents, which compensates for the lack of parameters. Baseline for 0 params is 4.

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 'Get the aggregated NMLP Knowledge Base' (specific verb+resource) and lists included content areas (donor archetypes, routing tracks, etc.), which distinguishes it from sibling tools like nmlp_get_archive or nmlp_get_business_card.

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 implies this tool is for retrieving the knowledge base but does not explicitly state when to use it over alternatives or provide any contextual guidance. No exclusions or alternative tool names are mentioned.

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 bears full responsibility for behavioral disclosure. It only states what the tool retrieves without mentioning side effects, safety, or limitations.

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, concise sentence that conveys the essential purpose without extraneous detail.

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 zero parameters and no output schema, the description is adequate but could provide more context about what the manifest contains or how to use the result.

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?

No parameters exist, so baseline score is 4 per guidelines. The description does not add parameter info, but none is needed.

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 verb 'Get' and the resource 'NMLP's pillar guide manifest', and distinguishes from sibling tools by its specific subject matter (60+ authentication and pricing guides).

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?

No guidance is provided on when to use this tool versus alternatives. It does not mention conditions, prerequisites, or 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?

No annotations provided, so description carries burden. Discloses returned fields, data source, and licensing, but does not mention error handling, speed, or limitations.

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?

Single paragraph, efficient. Every sentence contributes: purpose, required inputs, output contents, data source. No redundant words.

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?

Comprehensive for tool with no output schema: describes all returned elements, data source, licensing. Lacks mention of what happens if title not found or error cases.

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% with descriptions for both parameters. Description adds value by noting 'series/subtitle suffixes are fine' for title and that author 'strongly improves match accuracy'.

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?

Clearly states the tool identifies if a book is a first edition, specifying the verb 'identify' and resource 'first edition status'. Distinguishes itself from siblings by being 'THE tool' for this specific question.

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?

Implies usage by stating 'Given a title (and optionally author)' and returns details, but does not explicitly state when not to use or contrast with sibling tools like nmlp_decode_number_line.

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 bears the full burden. It discloses the returned fields, database size (20M+ records), and provides a human tool URL. It does not mention any destructive side effects, but the tool is clearly a read-only lookup.

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 and front-loaded, starting with the core purpose. It contains useful details without being overly verbose, though the human tool URL at the end is slightly extraneous for an AI agent.

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 tool has one parameter and no output schema or annotations. The description fully explains the input format, output fields, and data source, making it complete for an AI agent to use 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 schema already covers the single parameter with examples (100% coverage). The description adds context about dashes and spaces being optional and where to find the number, but this does not significantly enhance the schema's own description.

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 it resolves an LCCN to title, author, year, publisher, ISBN, and ASIN. It explains what an LCCN is and where to find it, making the purpose specific and distinct from siblings like nmlp_search_titles.

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 provides context for when to use the tool (for pre-ISBN books, reading number off copyright page) and mentions the data source. However, it does not explicitly state when not to use it or mention alternatives among the sibling tools.

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?

No annotations are provided, so the description carries the full burden. It discloses that the tool returns identification conventions across eras and notes the coverage scope. However, it does not describe the response format, error handling, or required permissions, though the tool's behavior is fairly straightforward.

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 concise, front-loaded sentences. The first sentence states the action and key details, and the second adds scope. There is no redundant 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?

Given the tool's simplicity (one required parameter, no output schema, no annotations), the description is largely complete. It could mention what happens if the publisher is not found, but overall it provides sufficient context for effective use.

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 schema coverage is 100% with a single parameter 'publisher' already well-described in the schema. The description adds context about coverage (850+ publishers) but does not add additional semantic meaning for the parameter beyond examples, earning a baseline score of 3.

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 looks up a publisher's first-edition identification conventions, specifying the types of conventions (stated-edition wording, number lines, colophons, dated printings) and coverage (850+ publishers). This distinguishes it from siblings like 'nmlp_identify_first_edition' which identifies a specific book, and 'nmlp_decode_number_line' which decodes a number line.

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 implies usage when needing to know a publisher's identification conventions, but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or 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?

No annotations provided, so description carries full burden. It discloses auto-detection, ranked candidates, missed-index reporting with dataset versions, and the non-appraisal/non-purchase policy. Lacks explicit read-only statement but implies it. Good but not perfect.

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?

Single paragraph, slightly long but well-structured. Front-loaded with purpose, then details, usage guidelines, and limitations. Could be broken into sections for readability.

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 no output schema, description adequately explains return behavior (ranked candidates, Attested Absence) and covers key aspects for a complex resolve tool. Complete for its purpose.

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% with a single parameter. Description adds context beyond schema: examples of valid inputs, case/format insensitivity, and special ISBN behavior (returns exact ASIN link).

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?

Clearly states the tool resolves any physical-media identifier, auto-detects type, and explicitly contrasts with specialized lookups like nmlp_cd_lookup, nmlp_lccn_lookup, and nmlp_vinyl_lookup.

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 ('when you don't know what kind of number') and when not to ('use specialized lookups when you do'), plus states it only identifies, does not appraise or buy.

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. It discloses a critical behavioral trait: 'Every submission triggers a real outreach to Josh, the single human operator.' This informs the agent of the real-world impact. It also warns against speculative use. Additional details like confirmation or idempotency would improve, but current disclosure is strong.

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, front-loaded with the primary purpose and followed by a crucial warning. Every word earns its place; there is no extraneous 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?

Given 12 parameters and no output schema, the description could be more complete. It does not explain the return value, success behavior, or how to handle errors. For a mutation tool with human operator involvement, more context about expected outcomes would help the agent.

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 low (17%), and the description does not add meaning for the 10 undocumented parameters. It only repeats the basic intent. The description should explain key parameters like address components or callback fields to compensate, but it does 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 clearly states the tool's purpose: 'Submit a real free book pickup request to NMLP.' The verb 'submit' and resource 'book pickup request' are specific. It distinguishes from sibling tools like nmlp_get_donation_options or nmlp_search_titles, which serve different functions.

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 a strong when-not-to-use guideline: 'NEVER submit speculative or unconsented requests.' This helps avoid misuse. It does not explicitly name alternative tools, but the warning is clear and valuable for decision-making.

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?

The description discloses that it returns top matching entries with specific fields (question, summary, URL), but lacks details on ordering, no-result behavior, or matching algorithm. With no annotations, the description provides basic but not comprehensive behavioral context.

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 concise sentence, but given the tool's simplicity and lack of annotations, it is adequate though not notably efficient. It could benefit from a bit more detail without becoming verbose.

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 fails to cover important aspects like how matching works, behavior on no results, or any nuances of the parameters. Given no output schema or annotations, the description leaves the agent with significant informational gaps for correct invocation.

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?

With schema description coverage at 0%, the description should compensate for parameter meanings. It only implies the 'query' parameter via 'by keyword' and completely ignores the 'limit' parameter, leaving its purpose and constraints unexplained.

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 specifies searching NMLP's long-tail Q&A reference by keyword and returns top matching entries with question, summary, and URL. It distinctly identifies the resource and action, setting it apart from sibling tools like nmlp_search_titles which likely search different content.

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?

No explicit guidance on when to use this tool versus alternatives is provided. The context implies it is for Q&A searches, but no when-not-to-use or alternative tool mentions are given, leaving the agent to infer usage.

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?

No annotations are provided, so the description bears full burden. It discloses that the tool is a read-only search returning URLs, which is adequate. However, it does not mention behavior related to the limit parameter or result pagination.

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 concise sentences, each adding value. No wasted words, and the alternative tool is front-loaded in the second sentence.

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 covers the tool's purpose, output, and alternative usage. It lacks explicit mention of the limit parameter's effect and output details, but it is sufficient for an agent to decide when to use this 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?

The description implicitly describes the query parameter as a title or author input, but the limit parameter is not mentioned at all. With 0% schema coverage, the description should explain both parameters.

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 searches the first-edition title reference by title or author and returns matching titles with URLs. It also distinguishes from sibling nmlp_identify_first_edition.

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 states when to use this tool (searching by title/author) and when to use an alternative (nmlp_identify_first_edition for full points of a specific title).

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?

No annotations provided, so description carries full burden. It discloses stable-prefix matching, fallback to MusicBrainz, and links to a grading checklist. Does not specify rate limits or error handling, but adds useful behavioral context.

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 sentences, each valuable. Purpose stated first, followed by behavior and fallback, then link. No fluff.

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 single-parameter lookup tool without output schema, the description fully covers input types, fallback, and return fields. Link adds optional depth.

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 meaning beyond the schema by explaining what 'identifier' can be (deadwax etching, catalog number, or barcode) and providing examples. Schema coverage is 100%.

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 identifies vinyl records from matrix/runout etching, catalog number, or barcode, and returns artist, album, year, label, catalog number. This distinguishes it from siblings like nmlp_cd_lookup.

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 specifies when to use the tool (for vinyl records) and mentions fallback sources, but does not explicitly exclude other media or provide when-not guidance. Context is clear.

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