financials
Return normalized high-value SEC XBRL metrics, not raw taxonomy fields.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | latest | |
| ticker | Yes | Ticker, company name, or SEC CIK |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes |
Return normalized high-value SEC XBRL metrics, not raw taxonomy fields.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | latest | |
| ticker | Yes | Ticker, company name, or SEC CIK |
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that results are normalized and curated ('high-value'), which is useful, but it does not mention the shape of returned data, period behavior, units, coverage, or limitations. This is a minimal behavioral sketch rather than a transparent description.
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 front-loaded sentence with no redundancy; the verb and resource appear first. The negative clause 'not raw taxonomy fields' is useful and earns its place. It could be richer, but as a concise statement it is well structured.
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?
Given the output schema and simple parameter set, an agent can infer the core call: pass a ticker and optionally a period. However, the large sibling list and lack of usage guidance create real selection ambiguity, and the absence of annotations leaves behavioral gaps. The definition is minimally viable but not complete.
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 only 50% — ticker has a meaningful description, but period has no description beyond its enum values. The tool description does not add semantics for period (latest/quarterly/annual) or explain how the normalization works. It names the data domain but does not compensate for the missing period documentation.
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 states an explicit verb ('Return') and a specific resource ('normalized high-value SEC XBRL metrics'), and it clarifies that the tool does not expose raw taxonomy fields. This gives an agent a concrete idea of what the tool produces. It doesn't explicitly differentiate it from sibling tools like financial_changes or company_snapshot, so it stops short of a 5.
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?
There is no statement of when to choose financials over alternatives such as financial_changes or company_snapshot, nor any conditions for use. The phrase 'not raw taxonomy fields' hints at scope but provides no actionable routing guidance.
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.