Altman Z-Score bankruptcy-risk screen for a US-listed ticker, inputs looked up automatically.
Scored across 1 tool
Only one tool exists, so there is no possibility of confusion or overlap. The single tool has a clearly defined purpose.
The lone tool name 'compute_altman_z_score' follows a clear verb_noun pattern. Even without other tools to compare, the naming is precise and conventional.
The server has just one tool, which feels thin compared to the typical 3-15 range. However, it is appropriate for a narrowly focused calculator that performs exactly one function.
For the stated purpose of computing an Altman Z-Score, the tool covers all necessary inputs and outputs. There are no obvious missing operations or dead ends for this domain.
Compute the Altman Z-Score (public-company, non-financial-services version) for a US-listed ticker -- a quick bankruptcy-risk / financial-distress screen from five balance-sheet ratios. Looks up working capital, total assets, retained earnings, EBIT, market cap, total liabilities, and revenue from SEC EDGAR + market data automatically -- just pass a ticker. Returns the score and which zone it falls in: safe (>2.99), grey (1.81-2.99), or distress (<1.81).
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | A US-listed ticker symbol, e.g. GE |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the operation as read-only and non-destructive. The description adds meaningful behavioral context: it states the data is retrieved automatically from SEC EDGAR + market data, that it uses five specific inputs, and that it returns both the score and a zone classification with numeric thresholds. This goes beyond the annotations to explain what the tool does internally and what the caller can expect.
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 two sentences with no filler. The first sentence front-loads the core purpose and scope; the second explains the automatic data lookup and the output format. Every clause contributes either to clarity, expected behavior, or result interpretation.
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 one well-documented parametercars, the description fully covers prerequisites (US-listed public company), data sources, and expected output (score + zone with thresholds). Since there is no output schema, the description carries the burden of explaining return values, and it does so explicitly. Nothing critical is missing for an agent to select and invoke this tool correctly.
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%, so the schema already fully documents the 'ticker' parameter as a US-listed symbol with an example ('GE'). The description reinforces this with 'just pass a ticker' but adds no new parameter-level meaning. This matches the baseline of 3 for fully covered schemas.
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 opens with a precise verb-resource-object statement: 'Compute the Altman Z-Score (public-company, non-financial-services version) for a US-listed ticker.' It further clarifies the purpose as a 'bankruptcy-risk / financial-distress screen' and names the five component ratios. There are no siblings to distinguish from, and the statement is unambiguous.
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 specifies the eligible scope: 'US-listed ticker' and 'public-company, non-financial-services version.' This implicitly communicates when the tool is appropriate and when it is not (e.g., private companies or financial firms). It also tells the agent that the user only needs to 'pass a ticker,' lowering the invocation barrier. No explicit exclusions or alternative tools are named, but with no siblings, the scope statement is sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
compute_altman_z_scoreBenjamin Graham's fair-value ceiling and margin of safety for a US-listed ticker.
Brina Gap valuation, screener and market score for US-listed stocks. SEC data, free, no key.
9,900+ US equities, 64 years of prices, financials, technicals, and earnings. Ask in plain English.
Free stock, ETF & crypto analysis: 10-point score, verdict and key metrics for any ticker.
Add one secure layer between your agents and this server.
