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

Annotations already declare readOnlyHint=true and destructiveHint=false, so no safety duplication is needed. The description adds valuable non-obvious behavior: the data sources (MBA CREF databook and Trepp public data) and the per-call cost ($0.02 USDC). These are meaningful beyond the annotations. It does not discuss pagination or default behavior, but for a simple benchmark lookup with a safety profile already provided, this is solid.

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 four short sentences, each earning its place: the core subject matter, the source, the audience, and the cost. It is front-loaded with the most important information and contains no filler or redundancy. This is an example of efficient, well-structured prose.

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 tool with only two simple parameters, no output schema, and a read-only annotation, the description is largely complete. It explains what the tool offers, who it serves, and the data provenance, plus the cost. It does not describe the output format or defaults, but given the simplicity and the absence of an output schema, this is not a significant gap.

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?

With schema_description_coverage at 0%, the description carries the burden for explaining parameters. It does name the two dimensions (property type and lender type) and lists some lender type values (bank, agency, CMBS, life company), but it omits 'debt_fund' and 'bridge' and gives no examples of property types. It tells the agent what the parameters mean at a high level but does not fully compensate for the missing schema descriptions or enumerate all allowed values.

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 the tool provides commercial real estate debt benchmarks and specifies the exact metrics (DSCR minimums, LTV maximums, spread ranges) and dimensions (property type, lender type). This goes beyond a bare restatement of the name, and the specificity distinguishes it from siblings like get_cap_rate_benchmark or get_credit_spread_benchmark. However, it lacks an explicit verb like 'retrieves' or 'returns', so the purpose is clear but slightly less direct than 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?

The description gives a clear target audience ('For CRE CFOs and capital markets teams structuring financings') and an implicit use case, but it does not name any alternative tools or state when not to use it. It implies usage via context rather than explicit guidance, so an agent might struggle to choose between this and closely related benchmarks like get_real_estate_debt_stress_benchmark.

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