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

Annotations already establish read-only, non-destructive behavior, so the description adds value by specifying matching semantics and the returned fields ('title, grant date, assignee, and inventors'). It does not go into pagination or edge cases, but the read-only disclosure lowers the burden and there is no contradiction with 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 three sentences with a clear order: function and matching scope, invocation constraint, returned fields. Every sentence contributes information and none of it is padded or redundant with the annotations.

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 having no output schema, the description covers what results look like and what inputs are required. It could be slightly more complete by pointing to patent_details for full records or explaining default limits, but the limit is already documented in the schema, so the remaining gap is minor.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds an important constraint that the schema's zero required fields do not convey: at least one of query, title, start_date, or end_date must be supplied. It also clarifies that 'query' matches title and abstract whereas 'title' matches title only, reinforcing schema semantics without repeating them verbatim.

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 ('Search'), a clear resource ('granted US patents'), and names the search dimensions (keyword in title/abstract, title, grant date range). It is unambiguous on its own, but it does not explicitly differentiate itself from sibling tools such as patent_assignee_search, patent_inventor_search, or patent_details.

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 states an explicit invocation condition ('Provide at least one of query, title, start_date, end_date'), which is useful guidance. However, it never tells an agent when to choose this tool over the nearby patent siblings, leaving that to inference from sibling names and parameter differences.

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