loc_search

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

With no annotations provided, the description carries the full burden. It discloses that no API key is needed and that the category parameter can restrict the search, which is useful behavioral context. However, it doesn't describe return format, pagination, rate limits, or other operational traits, leaving significant gaps for an unannotated 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 three sentences, front-loaded with the resource and purpose, and keeps extra details short. Every sentence earns its place, though the ordering of 'no API key' before the category instruction could be slightly improved. Overall it's concise and readable.

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 search tool with no output schema, the description doesn't explain what results look like or how to use related tools like loc_get_item. It mentions collection scope but lacks details on pagination, query syntax, or integration with siblings. The description provides a basic foundation but is incomplete for practical 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 description coverage is only 33% (only category has a description). The description reinforces category usage with examples but fails to explain 'query' (the required parameter) or 'pageSize' (with a default). Since coverage is low, the description should compensate more, but it does the bare minimum for category only.

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 identifies the tool as a search for the Library of Congress, using the verb 'Search' and a specific resource. It also lists the collection types, which adds useful scope. However, it doesn't explicitly contrast with sibling search tools, so it falls short of fully distinguishing itself beyond the resource name.

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 some usage context: it notes there is no API key and hints at using the category parameter to restrict results. But it doesn't explicitly state when to use this tool over other museum search tools (e.g., wellcome_search, met_search) or mention exclusion scenarios. The guidance is implied rather than explicit.

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