Full underwriting chain on a deal profile: financial integrity → trend →
industry position → stress tests → conviction score, plus a risk register and
investment thesis (and an rNPV valuation band for biotech deals with
indications). $2.00/call after free trial.
| Name | Required | Description | Default |
|---|---|---|---|
| deal | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the cost per call and the structure of outputs (risk register, investment thesis, rNPV band), plus a conditional behavior for biotech. However, it does not explicitly state whether the tool has side effects, requires authentication, or if it is read-only, leaving some ambiguity.
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, compact sentence that front-loads the purpose and lists the analysis steps and outputs in a clear, ordered fashion. It also includes the cost, which is useful, without any 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?
The description provides a solid overview of the analysis chain and expected outputs, and it mentions pricing. However, the tool is complex and the `deal` input object is entirely underspecified. Without an output schema or annotations, the description only partially guides an agent on how to invoke the tool and interpret results.
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?
The input schema has one unannotated object parameter with 0% description coverage. The description does not explain what fields the `deal` object should contain beyond hinting at `indications` for biotech deals. This is insufficient for an agent to construct a valid `deal` object.
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 clearly states it performs a 'full underwriting chain' on a deal profile, listing specific analyses (financial integrity, trend, industry position, stress tests, conviction score) and outputs (risk register, thesis, rNPV). This distinguishes it from sibling tools like company_report and validate_financials, which focus on reports or validation.
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 use for comprehensive deal underwriting and mentions a conditional for biotech deals with `indications`, but it does not explicitly state when to use this tool versus alternatives or provide any exclusion criteria. No alternative tools are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clear role: sec_extract retrieves raw data, validate_financials checks specific metrics, deal_score assesses a deal profile, and company_report produces a comprehensive report. Minor overlap exists between deal_score and validate_financials (both assess financial integrity), but descriptions distinguish them well enough.
All names are snake_case and readable, but they mix noun-first (company_report, deal_score), verb-first (validate_financials), and abbreviated noun-verb (sec_extract) patterns. This inconsistency is noticeable but not confusing.
Four tools is well-scoped for a financial analysis server: extraction, validation, deal scoring, and comprehensive reporting. Each tool earns its place without redundancy or bloat.
The tool set covers the full analysis pipeline: pull verified data (sec_extract), validate it (validate_financials), score specific deals (deal_score), and generate a comprehensive company report (company_report). No obvious dead ends or missing critical operations.