patentsview_lookup_ipc

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 candidly reveals a critical limitation (the service is discontinued) and suggests a recommended path forward. It could add more detail on what happens on invocation (e.g., error behavior), but it is highly transparent about the tool's operational status.

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 appropriately sized, starting with a clear one-sentence purpose, followed by a brief, critical API shutdown notice, and then the args. The warning is slightly verbose but justified given its importance; no unnecessary 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 the simple one-parameter schema and the presence of an output schema (which lessens the need to document return values), the description provides solid context: operational status, usage caveat, parameter meaning, and alternative guidance. It adequately covers the key aspects an agent would need to know.

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?

Despite 0% schema description coverage, the description documents the sole 'ipc_code' parameter with a concrete example ('G06F' for data processing). This compensates well for the bare schema and clarifies the expected input 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 'Look up IPC (International Patent Classification) code details' uses a specific verb ('look up') and clearly identifies the resource (IPC code). It's clear, though it doesn't explicitly contrast itself with siblings like patentsview_lookup_cpc, relying on the domain distinction to differentiate.

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 warns that the underlying API was shut down and provides a named alternative tool ('Use odp_search_datasets') for locating PatentsView bulk data with IPC data. This is an explicit when-not-to-use and alternative recommendation.

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