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 are provided, so the description carries the full burden. It discloses the output fields (coverage tier, pickup availability, minimum quantity, scheduling note), the routing logic (Albuquerque metro only), and a behavioral nuance: 'pickups are scheduled by route — no day-count window.' It also includes a conditional instruction for downstream action. This is exceptionally transparent for a check 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 dense paragraph, but it is well-structured: purpose, geographic scope, return list, and usage rule. It is front-loaded with the primary action. While it is somewhat verbose, every sentence contributes necessary context, and the critical instruction ('ALWAYS call this BEFORE...') is placed at the end but clearly emphasized.

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 output schema, the description must fully explain what the tool returns, and it does: the coverage tier enum, pickup availability, minimum quantity, scheduling note, and human-readable message. It also provides the usage context and the prerequisite relationship to scheduling. Nothing essential is missing for an agent to call it correctly and interpret 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?

The schema already documents the single parameter 'zip' with a pattern and description ('Five-digit US ZIP code'). The description repeats this information without adding new semantic detail (e.g., format constraints, examples, or special values). Since schema coverage is 100%, 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 states a specific verb ('Check'), a specific resource (NMLP book pickup coverage), and the input (five-digit US ZIP code). It clearly distinguishes itself from the sibling scheduling tool by positioning itself as a prerequisite, and it enumerates the output fields, leaving no ambiguity about what the tool does.

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 says 'ALWAYS call this BEFORE nmlp_schedule_pickup' and instructs not to submit a pickup request when pickupAvailable is false. It also explains the geographic coverage tiers (metro vs. elsewhere) which implies when the tool is relevant. This gives clear when-to-use and when-not-to-proceed guidance, with a direct reference to a sibling tool.

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?

With no annotations, the description carries the full burden. 'Get' plus the zero-parameter schema implies a safe read, and the description discloses the card's contents, which is genuinely useful. However, it says nothing explicit about read-only behavior, caching, or response format beyond the enumerated fields.

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 purpose, but the single run-on paragraph packs in drop-box logistics, load-size handling, phone instructions, and language policy. With no output schema these details arguably explain returns, yet the density and embedded instructions reduce crispness.

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-param getter with no output schema, the description reasonably covers what the card contains. It is close to complete for the agent's needs, though it could more clearly frame these as returned fields rather than instructions.

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 cannot supply parameter meaning; baseline is 4. The description correctly adds no parameter noise and instead explains the returned entity data.

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 NMLP's canonical business entity card') and enumerates the fields it returns (address, phone, services, area served, languages, drop box). Clear purpose, but it never contrasts itself against siblings like nmlp_get_knowledge or nmlp_get_donation_options, so differentiation is left to inference.

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?

There is no explicit when-to-use or when-not-to-use this tool versus the many sibling lookup tools. The operational details (warehouse hours, texting 505-250-3804, Spanish replies) describe NMLP's real-world services, not when an agent should call this tool.

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 present, so the description carries the burden of behavioral disclosure. It conveys that the tool returns a comparison matrix and is implicitly read-only, but it does not explicitly state whether it performs any side effects or how the matrix is structured. For a simple getter, this seems acceptable but not richly transparent.

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, focused sentence front-loads the action and resource, then provides illustrative examples. Every word earns its place; there is no repetition of the tool name and 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 zero-parameter, read-only lookup with no output schema, the description is sufficiently complete: it names the domain, scope, and contents. It could mention whether results are live or static, but that is a minor gap for this tool's simplicity.

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 the schema imposes no burden. The description adds value by explaining exactly what the returned comparison covers (specific organizations), which is the only semantic context an agent needs for a zero-parameter tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and resource ('comparison matrix of Albuquerque book donation options') and enumerates the included organizations. This distinguishes it clearly from sibling tools like nmlp_schedule_pickup or nmlp_search_titles, so an agent can select it 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?

The description makes the use case clear: retrieving a comparison of donation options in Albuquerque. It does not explicitly state when not to use it or name alternatives, but the context is unambiguous enough that an agent can infer this is the right tool for donation-option comparisons.

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 full burden of behavioral disclosure. It only says 'Get', implying a read-only operation, but does not mention potential side effects, rate limits, response size, or any special handling. For a knowledge-base retrieval tool, the agent has no indication of what to expect in terms of data volume or formatting.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that immediately states the purpose and then lists the key contents. Every word earns its place with no fluff or repetition. It is efficiently structured for quick scanning.

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 getter with no output schema, the description provides sufficient context by listing the main knowledge areas an agent will receive. It does not explain the return format or whether the response is large, but given the simplicity and the absence of an output schema, this is acceptable. It is nearly complete for the tool's straightforward nature.

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, so the schema is trivially complete. Per the rubric, a zero-parameter tool gets a baseline of 4, and the description correctly adds no unnecessary parameter details. There is nothing more to explain.

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 the aggregated NMLP Knowledge Base and enumerates its major content areas (donor archetypes, routing tracks, condition grades, decision framework, donor glossary, coverage tiers). This provides a specific verb+resource and distinguishes it from query-oriented tools like nmlp_search_qa, though it doesn't explicitly contrast with overlapping siblings like 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?

No guidance is given on when to use this tool versus alternatives. The description only states what it does, not when an agent should select it over siblings such as nmlp_search_qa or nmlp_get_pillar_guides. There are no conditions, exclusions, or recommended usage patterns.

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 discloses that the tool returns a manifest of 90+ guides and hints at the content of those guides, but it doesn't describe the return format, whether it's a list, pagination, or any side effects. For a read-only manifest retrieval, this is adequate but not rich.

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, information-dense sentence that front-loads the verb and resource, then adds relevant detail about the content. 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?

For a zero-parameter, read-only manifest retrieval, the description is largely complete. It could mention the return format or whether the manifest is a list of titles, but given the simplicity of the tool and no output schema, the description provides enough for an agent to 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 has zero parameters, so the schema is trivially complete. The description adds context about what the manifest contains, which is useful for an agent deciding whether to call this tool. Baseline 4 for zero params 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's purpose: retrieving NMLP's pillar guide manifest, with a specific resource (90+ Southwest author and collectible-book reference guides) and details on content (first-edition identification, points of issue, provenance). It distinguishes itself from sibling tools by focusing on the manifest of guides rather than individual lookups or searches.

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 is the tool to use when you need the overall manifest of pillar guides, as opposed to specific lookups like nmlp_identify_first_edition or nmlp_search_titles. It doesn't explicitly state when not to use it or name alternatives, but the context of sibling tools and the clear resource scope provide adequate 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?

With no annotations, the description carries the full burden of behavioral disclosure. It explicitly lists the output fields and mentions the data source and licensing (CC BY 4.0, DOI deposit), which gives the agent confidence in the tool's provenance and return shape. It does not mention error handling or rate limits, but for a read-only lookup this is sufficient.

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 three sentences, front-loaded with the purpose, then the output list, then a supporting data note. Every sentence adds value; the data provenance sentence is extra but useful for trust. It is not as terse as the two-sentence ideal but remains efficient and well-ordered.

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 two-parameter lookup with no output schema, the description does a good job of documenting what is returned (a detailed list of fields) and the data source. It does not mention edge cases like 'title not found' or multiple matches, but these are common to lookup tools and can be inferred. Overall, an agent has enough to 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?

Schema coverage is 100%, and the schema already documents both parameters, including that author improves match accuracy. The description merely restates 'given a title (and optionally author)' and does not add new meaning beyond the schema. It provides no additional syntax or formatting guidance, so it stays at the baseline for full coverage.

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 opens with a clear verb and resource: 'Identify whether a specific book is a first edition.' It then enumerates the exact outputs (POINTS OF ISSUE, precedence, tells, publisher, year, URL, citation), which distinguishes it from siblings like nmlp_search_titles or nmlp_decode_number_line. The emphatic 'THE tool' phrasing reinforces its specific role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a clear context: you use it when you have a title (and optionally author) and want to tell if a copy is a first edition. It implies this is the go-to for that question, but it does not explicitly list when to avoid it or name alternatives (e.g., nmlp_decode_number_line for number-line analysis). No exclusions are stated, but the context is unambiguous.

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 burden of behavioral disclosure. It conveys a read-only lookup and useful scope ('Covers 860+ publishers'), but it does not describe return format, matching behavior, or how unknown publishers are handled.

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 well-structured sentence front-loads the action and target, then adds specific examples and coverage scope. Every part earns its place and there is 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 one-parameter lookup with no output schema, the description explains what content is returned and across what eras. It is sufficient for selection and invocation, though it could mention response structure or not-found 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?

Schema description coverage is 100%, with a clear description of the 'publisher' parameter. The tool description does not add parameter-level detail, but the schema already fully documents the input. Baseline 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 uses a specific verb ('Look up') and resource ('publisher's first-edition identification conventions'), then lists concrete content categories. This clearly distinguishes it from siblings like nmlp_identify_first_edition or nmlp_decode_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 makes the intended use case clear: when you need a publisher's stated-edition wording, number lines, colophons, or dated printings. It does not explicitly name alternatives or exclusions, but the scope is unambiguous enough to route an agent correctly.

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?

No annotations are provided, so the description carries the full burden. It discloses the critical irreversible side effect that every submission triggers a real outreach to Josh, and it explains the outside-area fallback behavior. It stops short of describing the success confirmation or what the caller should expect after submission, but the most important behavioral risks are explicit.

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 with a distinct job: scope and action, real-world side effect, and safety/edge-case behavior. The content is front-loaded and every sentence earns its place without 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?

Given the high complexity (12 parameters, no output schema, irreversible real-world action), the description covers the essential safety and scope constraints well. However, it does not describe the successful return/confirmation behavior, route scheduling timing, or whether the agent should verify coverage beforehand, which are meaningful gaps for a tool with human impact.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 17%, and the description does not compensate by explaining the majority of the 12 parameters. It adds context about address-area behavior, but leaves donorName, callback fields, estimatedSize, preferredWindow, specialNotes, donorLanguage, and others without meaningful semantic guidance.

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 action ('Submit a real free book pickup request'), names the target system NMLP, and constrains the scope to the Albuquerque metro area. It is clearly differentiated from the sibling lookup/search tools by framing this as a real-world mutation with a human side effect.

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 gives an explicit when-not-to-use warning ('NEVER submit speculative or unconsented requests') and explains the edge behavior for outside-area addresses. It does not explicitly recommend a sibling like nmlp_check_coverage for pre-validation, but the usage context and exclusions are otherwise 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?

No annotations are provided, so the description carries the disclosure burden. It does add useful behavioral detail: keyword-based matching, top-result selection, and the output shape. However, it leaves ranking semantics, no-result behavior, and explicit read-only status implicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence that states the action, target resource, scale, and return fields in about 20 words. There is no filler, repetition, or buried 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?

For a simple two-parameter search tool with no output schema, the description gives the essential contract: what is searched, in what corpus, and what the returned entries contain. It is slightly thin on edge cases such as empty results and the effect of the limit parameter, but the core call contract is 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 0%, so the description should compensate for both parameters. It maps 'keyword' to query and 'top matching entries' loosely implies limit behavior, but it never names the limit parameter or explains its bounds/default. This leaves the optional parameter under-specified.

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 ('Search') and a specific resource ('NMLP's long-tail Q&A reference (80+ entries)'), and also names the return fields: question, summary, and URL. This gives the tool a distinct identity that separates it 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?

The description gives clear context: use this tool when you need to keyword-search NMLP's Q&A reference. It does not explicitly list when-not-to-use cases or point to an alternative sibling, so it falls short of a 5, but the intended usage is unambiguous.

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.