Skip to main content
Glama
Sign In

Clarifo

by com.clarifo
OverviewDiscussionsAdmin

forecast_financials

Read-onlyIdempotent

Project a financial metric forward for a US or Nordic company, deterministically from its own filed history, with a read on fit quality.

Chart: per the server "Charts" guidance; in ChatGPT call render_chart(source_tool="forecast_financials", source_args=, output="python").

Args: company: Name or ticker (fuzzy), e.g. "Apple", "AAPL". metric: "revenue" (default), "ebit", "ebitda" (Nordic only), "net_income", "operating_cash_flow", "free_cash_flow". horizon: Future years (1-10, default 3). method: "auto" (default; log-linear when all history is positive and >= 3 years, else linear), "log_linear", "linear" or "driver" (uses growth_rate). growth_rate: Fraction (0.08) or per-year list ([0.12, 0.10, 0.08]); applies with "auto" or "driver", ignored with "linear" / "log_linear". market: "nordic" or "us"; omit to auto-detect.

Returns {company, metric, method_used, historical, forecast, cagr, r_squared, coverage, quality_notes}; surface quality_notes. Error: {"error": "..."}.

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": {
      "company": "<company>"
    },
    "name": "forecast_financials"
  }
}

Input Schema

NameRequiredDescriptionDefault
marketNo
methodNoauto
metricNorevenue
companyYes
horizonNo
growth_rateNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already establish readOnly/idempotent/non-destructive/closed-world, and the description goes further by stating the forecast is deterministic from filed history, that 'auto' silently falls back to linear when history is non-positive or under 3 years, that growth_rate is ignored under linear/log_linear, and that quality_notes should be surfaced. It does not address coverage limits beyond the returned 'coverage' field or any latency/cost traits, so it stops short of fully rich behavioral context.

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?

The lead sentence is a dense, front-loaded summary, and the Args block is scannable with one line per parameter. The charting paragraph is somewhat integration-specific plumbing, but it is short and actionable rather than filler.

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?

For a six-parameter projection tool this covers everything an agent needs: argument semantics, method-selection behavior, the return key set with an instruction to surface quality_notes, and the error contract. An output schema exists, but restating the keys is harmless and the method/quality caveats are the parts the schema could not convey.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the full burden and does: it documents every one of the six parameters with defaults, example values, valid ranges (horizon 1-10), allowed metric strings including the 'ebitda' Nordic-only restriction, and the number-or-list form of growth_rate. It also explains interactive effects the schema cannot express, such as growth_rate being ignored with linear/log_linear and market auto-detecting when omitted.

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 and resource ('Project a financial metric forward') plus the scope constraint ('for a US or Nordic company, deterministically from its own filed history'), which separates it from historical siblings like get_company_financials. It also flags what the output is good for ('a read on fit quality').

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?

Gives concrete selection logic for the method parameter (auto vs log_linear vs linear vs driver) and for when growth_rate applies, and it routes charting follow-up to render_chart with the correct source_tool/source_args. It never names a sibling that should be used instead when the user wants actuals rather than projections, so the when-not case is left implicit.

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

All Clarifo 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