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

Beyond the annotations (readOnly, idempotent, non-destructive, closed-world), the description adds substantial behavior the annotations cannot express: attribution through a reviewed CIK binding, the answer naming that relationship, and a full taxonomy of named refusals (not_listed, no_match, ambiguous, no_selection_held, no_publishable_metric). The explicit promise of "never a zero" is exactly the kind of failure-mode disclosure an agent needs to avoid misreading an empty result.

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 content is well front-loaded: the resource and its provenance come first, then the input form, then the attribution caveat, then the refusal codes. Four sentences carry a lot of signal with little waste, though the refusal enumeration reads as a terse code dump that could be tightened.

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?

With no output schema, the description carries the return-value burden and does so: it names the metrics (revenue, net income and the like), states the answer includes the registrant relationship, and enumerates the refusal outcomes. For a one-parameter lookup whose complexity lies in coverage and attribution, nothing an agent needs in order to call or interpret it is missing.

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 single param `q` is already documented as a lender name or digits NMLS, so the description's "Ask with a lender name or its company NMLS" largely restates the schema. It adds only a marginal nuance that NMLS refers to the company (not individual) identifier, which is the baseline 3 for a fully documented single 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 states a specific resource and its provenance: "One lender's published SEC-filed parent figures: revenue, net income and the like, taken from the annual or quarterly filing." It also clarifies the figures belong to the REGISTRANT (e.g., Rocket Companies for Rocket Mortgage), which is a real disambiguation. It falls short of 5 because it never names the near-identical sibling get_lender_figures, leaving the agent to infer the split on its own.

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 tells the agent how to invoke ("Ask with a lender name or its company NMLS") and sets a clear eligibility boundary: only lenders with a reviewed CIK binding can answer, everyone else gets a refusal. What's missing is any explicit routing advice against alternatives such as get_lender_figures or get_lender_universe, so the when-not case is covered only for data availability, not tool choice.

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