Onça Setorial

Company financials from CVM filings (DFP/ITR)

company_financials

Read-onlyIdempotent

Revenue, net income, assets, equity, EBIT, D&A for a Brazilian listed company in your licensed sectors, from its own CVM filings: the annual DFP and the latest quarterly ITR (year-to-date). Derived values (EBITDA, net debt, margins, leverage) are returned separately and labelled estimativa. A company with no CVM filing says so (closed capital or IR-page only) instead of returning numbers. Use for 'what was X's revenue / net income / debt'. Deterministic: computed from official datasets, no model in the loop.

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": {
      "entity": "<entity>"
    },
    "name": "company_financials"
  }
}

Input Schema

Name	Required	Description	Default
`entity`	Yes	Company name or Onça Setorial id, e.g. 'Vale', 'Eletrobras', 'Hypera'.
`period`	No	Optional. '2025' or '2025-12-31' for the annual DFP; '2T26', '2026Q2' or '2026-06-30' for a quarterly ITR. Default: every statement on file.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive semantics, yet the description still adds substantive behavior: derived figures (EBITDA, net debt, margins, leverage) come back separately and are flagged 'estimativa', and a company with no filing is reported as such instead of returning fabricated numbers. It also asserts determinism ('no model in the loop'). The one undisclosed trait is the 'licensed sectors' gating — what happens when a company falls outside the license is not stated.

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?

Two dense sentences, each clause carrying content: metric list first, then source, then derived-data caveat, then no-filing fallback, then usage trigger and determinism note. Semicolon-heavy but not padded; nothing reads as filler.

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

Completeness4/5

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

With no output schema, the description must carry the return-shape burden, and it does so adequately by enumerating the fields and marking estimates. Remaining gaps are currency/units and result granularity (single company snapshot vs. multi-period series), which are minor for a two-parameter lookup.

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 100%, so baseline is 3, but the description earns an increment by explaining that the ITR figures are year-to-date and that DFP is annual, which clarifies what the period parameter actually selects. It still leaves the entity identifier's resolution behavior unspecified, which the schema already handles with examples.

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?

The description names the exact metrics returned (revenue, net income, assets, equity, EBIT, D&A), the subject (a Brazilian listed company), and the source system (its own CVM DFP/ITR filings). No sibling tool in the list does anything similar, so the agent can identify this as the fundamental-data tool without ambiguity.

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?

It gives an explicit trigger phrase — 'Use for what was X's revenue / net income / debt' — which maps a user question directly to this tool. It does not name an alternative or state when not to use it, but the sibling set contains no overlapping financials tool, so the absence of exclusions is a minor gap rather than a real risk.

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

All Onça Setorial tools Inspect

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

Need Help?