Skip to main content
Glama
arhancanli

canli-validation-mcp

by arhancanli
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

Company financial history (SEC)

company_financial_history
Read-only

Validate a backtest by checking a company's SEC-reported financials by CIK or ticker: list us-gaap concepts or get observations with filing details and source hash.

Instructions

SEC-reported financial history for one company from the canlicapital.com company reference (GET /company-data/{cik}.json), by cik or by ticker (resolved through GET /api/v1/company-tickers.json, companies in the release only). Without a concept it lists the available histories; with one it returns observations, newest first, each with its filing accession, form, filed date and unit, plus the SHA-256 of the original SEC response. No key required. Public company accounting reference, not market prices, returns, an investment recommendation, or ALPHAC performance. Validate a separately constructed return series with the validation API; accounting values are not returns.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cikNoSEC CIK; send cik or ticker.
limitNoMost observations, newest first; default 40.
tickerNoTicker such as AAPL; send ticker or cik.
conceptNous-gaap concept such as Assets; omit to list them.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.6.0
    • addedInput schema / properties / cik / description
      Added value: +"SEC CIK; send cik or ticker."
    • addedInput schema / properties / concept / description
      Added value: +"us-gaap concept such as Assets; omit to list them."
    • addedInput schema / properties / limit / description
      Added value: +"Most observations, newest first; default 40."
    • addedInput schema / properties / ticker / description
      Added value: +"Ticker such as AAPL; send ticker or cik."
  2. First observedv0.5.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnly/openWorld/destructive annotations, the description adds meaningful context: no API key required, ticker resolution through a separate endpoint, companies only in the release, newest-first ordering, and the SHA-256 of the original SEC response. This gives a clear behavioral model.

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

Conciseness5/5

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

The description is dense but purposeful, with the core purpose front-loaded and every sentence adding useful information. It balances source, behavior, authentication, and disclaimers without wasted words.

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?

Even though there is no output schema, the description explains what is returned in both modeschers, including filing accession, form, filed date, unit, and SHA-256. It also covers key context such as the release-only company universe, no-key access, and the boundary between accounting data and return validation.

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 the schema already documents cik, ticker, limit, and concept. The description adds extra semantic value by explaining that omitting concept lists available histories while including one returns observations, and by describing ticker resolution through the company-tickers endpoint.

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 states a specific verb and resource: it returns SEC-reported financial history for one company, and distinguishes list mode from observation mode. It also explicitly separates itself from validation and performance APIs by noting accounting values are not returns.

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?

The description clearly explains behavior with and without a concept, and explicitly directs users to the validation API when they need to validate return series. It does not enumerate sibling tools by name, but the alternatives are sufficiently identified.

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

Deploy Server

Other Tools