Skip to main content
Glama

Finviz-only: SEC filing history

stock_filings

Retrieve SEC filing history for a ticker from Finviz, filtered by form type and paginated. Use it to review 10-K, 10-Q, and other filings when TradingView lacks a filing feed.

Instructions

SEC filing history for a ticker (Finviz-only, single-source).

TradingView has no filing feed, so this capability cannot be cross-verified. The response is labelled FINVIZ and the notice says so.

Args: symbol: Ticker. page: 1-based page. page_size: Rows per page (1-100). forms: Optional SEC form filter, e.g. "10-K,10-Q".

Returns: Envelope with the filing rows plus has_more.

Input Schema

NameRequiredDescriptionDefault
pageNo
formsNo
symbolYes
page_sizeNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description usefully discloses single-source provenance, the lack of cross-verification, FINVIZ response labeling and notice, and pagination through has_more. It does not explicitly state read-only behavior or operational limits, although the filing-history wording strongly implies a non-mutating retrieval.

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 purpose and source limitation are front-loaded, followed by compact Args and Returns sections. The labeling sentence reinforces the provenance caveat, and there is no substantial filler or unnecessary elaboration.

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 straightforward four-parameter filing-history lookup, the description covers scope, provenance, verification limitations, filtering, pagination, and the response envelope. Defaults remain available in the input schema, while the output schema can supply detailed return fields, leaving no material invocation gap.

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?

Despite 0% schema description coverage, the Args section documents all four parameters. It adds 1-based pagination, the 1-100 page-size range, optional form filtering, and a concrete comma-separated forms example, supplying the details needed for correct invocation.

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

Purpose4/5

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

Clearly identifies the resource (SEC filing history), scope (one ticker), and source (Finviz-only, single-source). Its subject matter distinguishes it from quote, news, and earnings siblings, but it does not explicitly route away from any named alternative.

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 source restriction and explanation that TradingView cannot cross-verify filings provide concrete context for choosing the tool and interpreting its results. There is no explicit when-not guidance or named alternative for other company-data needs, so selection guidance is not exhaustive.

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