VLN Capabilities Overview

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

The readOnlyHint annotation already indicates no destructive effects. The description adds transparency about what is returned (structured overview, compact JSON if low_tokens=true) and the domain context (finsec.caleralabs.com), which is valuable beyond the annotation alone.

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 a single, well-structured sentence that front-loads the key action and resource, enumerates major content categories, and specifies the platform domain. No wasted words; every element earns its place.

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 tool has no required parameters, a rich output schema (not shown but present), and annotations cover read-only safety, the description is complete enough. It explains what categories are included and the optional parameter effect, though it could briefly note that the output is a single JSON object format.

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 description coverage is 100% and there is only one optional parameter. The description adds value by explaining that low_tokens affects structure ('compact JSON schema'), which goes beyond the schema's brief description. It efficiently covers the parameter's impact on output 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 uses specific verbs ('Returns') and a clear resource ('structured overview of all VLN capabilities'), listing included categories (EDGAR valuation packs, Domain 31 operations, SEC calculations). It differentiates from siblings by being a single source of truth overview vs. the specific computation tools like compute_sec_cagr or lattice_arith_evaluate.

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 implies when to use it (to get a complete overview of capabilities) and the scope ('product scope boundaries on finsec.caleralabs.com'). It does not explicitly say when not to use it (e.g., for specific valuations use sibling tools), but the sibling context and tool name make this clear.

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