Skip to main content
Glama
Sign In

EdgarStack

by com.edgarstack
OverviewDiscussionsAdmin

Analyze earnings quality and unusual changes

analyze_earnings_quality
Read-onlyIdempotent

Two screening views on a company's SEC XBRL numbers:

  • view="indicators" (default): accruals, cash conversion, working-capital days trends, and revenue versus receivables growth, with the thresholds and methodology used.

  • view="anomalies": flags the latest annual or reported-quarterly growth in up to 8 metrics (default revenue, operatingIncome, netIncome, operatingCashFlow, capex) when it falls outside the company's own history. A review signal requires at least four earlier comparable growth observations and a latest value beyond the historical 1.5× IQR fence by at least 10 percentage points; limit 6–10 observations per metric, default 8. Unavailable values are null. Results are indicators and prompts to review the source filings, not findings or verdicts; they can be affected by industry, seasonality, acquisitions, factoring, and reporting changes. Not financial advice.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "ticker": "<ticker>"
    },
    "name": "analyze_earnings_quality"
  }
}

Input Schema

NameRequiredDescriptionDefault
viewNoindicators
limitNoview=anomalies only: observations per metric; at least six are needed for a baseline
periodNoview=anomalies only: annual 10-K values or reported quarterly 10-Q valuesannual
tickerYesUS ticker symbol
metricsNoview=anomalies only: one to eight metrics; omit for the defaults

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: it discloses the statistical rule (four prior observations, 1.5× IQR fence plus 10 percentage points), the metric defaults for the anomalies view, and that unavailable values are null. The disclaimer that results are review prompts, not verdicts, and the list of confounders (industry, seasonality, acquisitions, factoring) is behavior an agent could not infer from structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the two views and structured as per-view bullets, so scanning yields the decision quickly. The closing caveat sentence is dense but earns its place; a small amount of the threshold detail could be trimmed without loss.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description compensates by saying results are indicators plus methodology, that unavailable values are null, and what each view yields. For a 5-parameter analytical tool with no output contract, nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 80%, so the baseline is 3; the description adds real meaning by tying limit/period/metrics to view='anomalies' only, explaining that six observations are needed for a baseline, and stating that metrics may be omitted for the defaults. It also repeats defaults and min/max values already present in the schema, which adds no credit.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('two screening views on a company's SEC XBRL numbers') and immediately decomposes it into two named modes with distinct outputs. An agent can tell this apart from compute_ratios or assess_financial_data_quality without consulting the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly explains when to pick view='indicators' (accruals, cash conversion, working-capital days, revenue vs receivables) versus view='anomalies' (growth outside the company's own history), which is exactly the selection decision an agent faces. It stops short of naming sibling tools or stating when a different tool (e.g. compute_ratios, assess_financial_data_quality) would be a better call.

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

All EdgarStack toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources