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

With no annotations, the description carries full burden. It discloses return data and implies a read-only check. No side effects are mentioned, but error behavior is not covered.

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 concise sentences: purpose, return fields, and a critical usage instruction. No verbose or redundant content.

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 one parameter fully covered by schema and no output schema, the description provides sufficient context for correct usage. Lacks error handling details but is generally 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 single parameter 'zip' is fully described in the schema (100% coverage). The description adds no additional semantics beyond restating 'five-digit US ZIP code', so 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 clearly states the tool checks coverage at a five-digit ZIP code, listing return fields and explicitly distinguishing from nmlp_schedule_pickup with an ordering instruction.

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', providing clear when-to-use guidance, but lacks when-not-to-use or alternative 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?

With no annotations, the description carries full burden. It discloses handling the 'Random-House-ends-in-2 exception' and flagging book-club editions, and states the return values (printing, verdict, detected line), which provides good transparency.

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 (3 sentences), front-loaded with purpose, and every sentence adds value. 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 a single parameter and no output schema, the description covers the tool's functionality, exceptions, and return details. It is complete enough 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?

Schema coverage is 100%, and the schema already describes the parameter well. The description adds context about the type of text and the exceptions handled, reinforcing the schema and providing complementary information.

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: 'decode a copyright-page number line / printer's key' to determine printing. It specifies what to paste and mentions handling exceptions, distinguishing it from sibling tools like 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 tells when to use the tool (to determine printing) and implicitly when not (if no number line). It does not explicitly name alternatives, but given siblings like nmlp_identify_first_edition and nmlp_lookup_publisher_rules, the usage 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?

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It implies a read operation but does not explicitly state that it is read-only, nor does it mention side effects, authentication needs, rate limits, or data freshness. With no annotations, this is insufficient.

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 immediately conveys the tool's purpose without any 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?

The description mentions 'structured Book records' but does not define this term or explain the output structure, and there is no output schema. For a simple get-all tool, it is minimally acceptable but lacks detail on what 'Book records' contain.

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 zero parameters, so schema coverage is 100% vacuously. The description adds no parameter-specific value, but the baseline for 0 parameters is 4, as the schema already covers all aspects.

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 donation archive entries', and specifies the output format as 'structured Book records'. It distinguishes itself from siblings like nmlp_get_donation_options by focusing on archive entries.

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 alternatives, no prerequisites, and no conditions for use. It simply states what it does without any when-to or when-not-to context.

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 exist, so the description must carry the behavioral burden. It indicates a read-only retrieval (by name 'get') and lists returned fields, but does not explicitly state safety, authentication needs, or side effects. The lack of explicit safety language is a minor gap.

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

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

A single, well-structured sentence that immediately conveys the tool's purpose and content. No extraneous words; each word adds value.

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 retrieval tool without an output schema, the description fully captures the return structure (address, phone, services, area served, languages). The term 'canonical business entity card' clarifies authority. No additional context is needed.

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 has zero parameters, so schema coverage is vacuously 100%. Per guidelines, 0 parameters merit a baseline of 4. The description correctly omits parameter details as none exist.

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 identifies the resource as 'NMLP's canonical business entity card.' It lists the contained fields (address, phone, services, area served, languages), clearly distinguishing it from sibling tools that retrieve other data types.

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 like nmlp_get_archive or nmlp_get_knowledge. The description only states what it does, not the context for its 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 fully carries the burden of behavioral disclosure. It lacks details on whether the matrix includes policies, condition requirements, or whether data is live. A 2 reflects moderate gaps in transparency.

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 with no wasted words, front-loading the core action. It is appropriately sized for a simple tool with no parameters.

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, the description lists organizations but fails to specify the comparison dimensions (e.g., factors like acceptance criteria, drop-off hours). This leaves agents guessing about the output format, making it moderately incomplete.

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 zero parameters, so schema coverage is 100%. The description adds value by clarifying that the output is a 'comparison matrix' listing specific organizations, which goes beyond the empty schema. 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 the tool returns a comparison matrix of all Albuquerque book donation options, listing specific organizations. The verb 'Get' and resource 'comparison matrix' are precise, and it distinguishes itself from sibling tools (none mention donations).

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 for comparing donation options but does not explicitly state when to use it (e.g., when deciding where to donate) or mention alternatives. Since it's a unique tool among siblings, the lack of exclusions is acceptable.

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, and the description only states what the tool retrieves without disclosing any behavioral traits such as read-only nature, rate limits, or potential errors. The description does not compensate for the missing annotations.

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

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

The description is a single sentence that efficiently conveys the tool's purpose and content. It is front-loaded with the key action and resource, though the list of items could be slightly streamlined.

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 tool with no output schema or annotations, the description provides a clear summary of what the tool returns. It lacks details on output format or size, but for this simple tool, it is reasonably 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 tool has zero parameters, and the schema coverage is 100% (empty). The description adds meaning by enumerating the contents of the knowledge base, which helps the agent understand what the output will include.

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 'aggregated NMLP Knowledge Base', and lists specific subcomponents (donor archetypes, routing tracks, etc.), which distinguishes it from sibling tools that are more specific lookups or actions.

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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. The agent is left to infer usage without explicit context.

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 must provide behavioral context. While it indicates a read operation ('Get'), it does not disclose whether the manifest is cached, if there are rate limits, or the nature of the response (e.g., a list vs. detailed content).

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, efficient sentence that conveys the core purpose and content without unnecessary words. It is front-loaded with the verb and resource.

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 parameters and no output schema, the description adequately explains the tool's function. However, it could mention how the manifest relates to other tools (e.g., for fetching individual guides), which would improve completeness for an 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?

The input schema has no parameters, so schema coverage is 100%. The description adds value by explaining what the retrieved manifest contains ('60+ ... guides'), which aids the agent in understanding the output without needing parameter details.

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 with a specific verb ('Get') and resource ('NMLP's pillar guide manifest'), and distinguishes it from siblings by specifying the content: '60+ Southwest author/publisher 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 alternative tools like nmlp_get_archive or nmlp_search_titles. The description does not mention prerequisites or context for use.

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 full burden. It explains what the tool returns (points of issue, precedence, tells, publisher, year, page URL, citation) and cites the dataset with licensing (CC BY 4.0, DOI). It does not mention side effects, rate limits, or failure handling, but as a read-only query tool, the disclosure is sufficient for typical use.

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 focused paragraph. It front-loads the purpose, lists key outputs, emphasizes the tool's role, and cites the data source. Every sentence earns its place with no redundancy or 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?

Given no output schema, the description sufficiently explains return fields and data provenance. It covers the two parameters with practical guidance. The tool is straightforward, and the description addresses all necessary context for an AI agent to invoke it correctly.

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

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

Schema coverage is 100%, so both parameters are described. The description adds useful context beyond the schema: for 'title' it notes 'series/subtitle suffixes are fine', and for 'author' it states 'strongly improves match accuracy for common titles'. This helps the agent understand when to provide the optional parameter.

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: 'Identify whether a specific book is a first edition.' It uses a specific verb ('identify') and resource ('first edition'), and distinguishes itself from siblings by claiming to be 'THE tool' for that question, which sets it apart from related tools like 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 indicates when to use: given a title and optionally author. It emphasizes it's the primary tool for first-edition identification. However, it lacks explicit when-not-to-use guidance or references to alternative tools (e.g., when to use nmlp_check_coverage or nmlp_decode_number_line), leaving some ambiguity for edge cases.

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 describes the tool as a lookup, implying it is read-only and non-destructive, but does not explicitly state side effects, authorization needs, or data freshness. For a simple lookup, this is adequate but could benefit from stating that it only returns information and does not modify any data.

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

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

The description is two sentences, front-loading the main action and adding concise detail about what is covered. No unnecessary words; every sentence adds value.

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 provides sufficient context for the tool's purpose and output (conventions, wording, number lines, etc.) and notes the coverage of 850+ publishers. It does not specify return format or error handling, but for a simple lookup tool this is acceptable. Could mention handling of missing publishers.

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 has 100% coverage with one parameter 'publisher' described with an example list. The description adds no additional semantic meaning beyond the schema; it merely restates the parameter's role. With high coverage, baseline is 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's purpose: to look up a publisher's first-edition identification conventions. It specifies the types of information covered (stated-edition wording, number lines, colophons, dated printings) and the scope (850+ publishers). This clearly differentiates it from siblings like 'nmlp_identify_first_edition' (which identifies a book's edition) and 'nmlp_decode_number_line' (which decodes a specific 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 the tool is used for looking up publisher conventions but does not explicitly state when to use it versus alternatives like 'nmlp_check_coverage' or 'nmlp_identify_first_edition'. There is no guidance on 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 are provided, so the description carries full burden. It discloses a critical behavioral trait: every submission triggers real outreach to a single human operator (Josh). This is valuable for the agent to understand the irreversible, human-in-the-loop nature. However, it does not disclose response behavior (e.g., confirmation, error handling).

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, each earning its place. The first sentence states the core action, and the second adds a critical warning. No redundant or irrelevant content.

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, 6 required, no output schema, and no annotations, the description is insufficient. It does not explain the outcome of the submission (e.g., confirmation ID, follow-up), prerequisites (e.g., user account, cost), or geographic scope (NMLP likely refers to New Mexico but not stated). The agent lacks key context to use the tool correctly and safely.

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% (2 of 12 parameters documented in schema). The description adds no parameter-specific information beyond what is in the schema. Parameters like donorName, addressStreet, specialNotes remain unexplained, leaving the agent without guidance on their format or purpose.

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 ('Submit a real free book pickup request') and the resource ('to NMLP'). It distinguishes from sibling tools, which are all informational lookups (e.g., nmlp_check_coverage, nmlp_search_titles), by emphasizing the action of scheduling a pickup.

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 explicit context: every submission triggers real outreach to a human operator, and warns against speculative or unconsented requests. This implies when to use (real, consented requests) and when not to (speculation). However, it does not explicitly name an alternative tool for different purposes.

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 indicates 'Returns top matching entries' and lists output fields, but does not disclose whether the operation is read-only, idempotent, or any side effects. The search action implies non-destructive behavior, but details are lacking.

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, concise and front-loaded with purpose. However, it could be slightly more structured by explicitly listing parameters or usage scenarios. Overall, 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 no output schema, the description adequately specifies the return structure (question, summary, URL). However, it lacks details on ordering, pagination, error handling, or how 'top matching' is determined. For a search tool with two parameters and siblings, more context would be helpful.

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 must compensate. It only mentions 'by keyword', which relates to the 'query' parameter, but does not explain the 'limit' parameter (shown in schema with default 5, max 20). The description adds minimal value beyond the parameter names.

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 'Search', specifies the resource 'NMLP's long-tail Q&A reference (85+ entries)', and describes the output format 'question, summary, and URL'. This distinguishes it from sibling tools 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 implies usage for keyword-based Q&A searching but does not explicitly state when to use this tool versus alternatives (e.g., nmlp_search_titles for book titles). No 'when not to use' or exclusions are provided.

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 should disclose behavioral traits. It mentions searching and returning URLs but omits read-only nature, rate limits, ordering, or pagination behaviors. The description provides basic functionality but lacks deeper 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?

Two concise sentences: first defines the action and output, second directs to an alternative. No wasted words, front-loaded with key 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?

Covers the main purpose and sibling reference, but omits details about return structure (beyond URLs), limit behavior, and potential edge cases. For a simple search tool, it is adequate but not fully complete.

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

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

Schema description coverage is 0%, so the description must explain parameters. It only explains that 'query' is searched by title or author, but does not describe the 'limit' parameter at all. Partial coverage leaves ambiguity for the limit behavior.

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 a reference by title or author and returns matching titles with URLs. It also distinguishes itself from the sibling nmlp_identify_first_edition, making the purpose unambiguous.

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 instructs to use nmlp_identify_first_edition for full details on a specific title, providing clear context on when to use this tool versus an alternative.

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