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

With no annotations, the description carries the burden and does add real context: pagination with a 30-record default page, gateway-based credentialing, and that charges/authorization are decided by the gateway. It is silent on rate limits and on the response payload shape, but the read-only nature is implied by 'Retrieve'.

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 short sentences, front-loaded with the operation and identifiers before the pagination and billing notes. The gateway-credential sentence is somewhat boilerplate but does convey non-obvious auth behavior, so nothing is truly wasted.

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 3-parameter read tool with no annotations and no output schema, the description covers the essentials: what is returned (patent records, paginated at 30/page), how the enterprise is identified, and how auth/billing works. The remaining gap is return-field detail and behavior when no identifier is supplied.

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, but the description adds meaning the schema does not: enterprise ID and unified social credit code are alternatives ('or'), which matters because the schema marks zero required parameters and an agent could otherwise assume both are needed. It still does not say what happens if neither is passed.

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 ('Retrieve patent records for an enterprise') plus the two identifying keys, so an agent knows this is the patent sub-resource rather than the brand, ICP, or software-copyright siblings. It does not explicitly name any sibling alternative, which keeps it short of a 5.

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?

Implicit usage is clear (call it when you need patents for a known enterprise), and it tells you which identifiers to supply. However, it never says when to prefer this over related tools such as the IPR patent lookup or the enterprise write-list tools, and gives no prerequisite guidance such as needing a resolved enterprise ID first.

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