Skip to main content
Glama

Signal Nodus SEC Filings

Diff a section across two filings

compare_filings
Read-only

Year-over-year diff of a 10-K risk-factor or MD&A section: the added and removed passages plus a change ratio, so an agent gets what changed instead of two multi-megabyte filings to parse. Pass two accession numbers to pin exactly which filings are compared; otherwise the two most recent of that form are used and the response says which, warning if a later amendment exists. Failure mode: if either section cannot be located or parsed into sentences, the call errors rather than reporting a false 0% change. Diff accuracy and method are published at signalnodus.ai/eval. Two large cold filings can take tens of seconds. Costs $0.50 per call. No subscription: present a credit key or a machine payment.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formNo10-K or 10-Q. Default 10-K.
itemNoItem to compare, e.g. 1A for risk factors. Default 1A.
companyYesTicker symbol (e.g. AAPL) or SEC CIK number (e.g. 320193).
max_passagesNoCap on added/removed passages returned. Default 40.
to_accessionNoNewer filing to compare to.
from_accessionNoOlder filing to compare from.

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnly and openWorld annotations, the description discloses several important behaviors: it errors rather than returning a misleading 0% change, warns about later amendments, reports which filings were compared, can take tens of seconds, and costs $0.50 per call. This is rich, actionable 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 description is dense but efficient, front-loading the core purpose and then covering usage, failure modes, performance, and cost. A few extras like the evaluation link could be trimmed, but the structure is logical and every sentence carries useful information.

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 without an output schema, the description explains enough about the result format, fallback behavior, failure conditions, latency, and authentication requirement for an agent to call the tool correctly. Nothing critical for invocation is missing.

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 baseline is 3. The description adds value by explaining the role of accession parameters in controlling which filings are compared, and by clarifying that omitted accessions fall back to the two most recent filings. This goes beyond the schema's field-level descriptions.

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 a specific verb ('diff') and resource ('a 10-K risk-factor or MD&A section'), and clearly states the output: added and removed passages plus a change ratio. This distinguishes it from sibling tools like filing_section or edgar_search, which fetch or search rather than compare.

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 gives concrete guidance on how to pin exact filings using accession numbers and what happens when they are omitted, including amendment warnings. It does not explicitly name alternative sibling tools or state when not to use this tool, but the intended context is clear.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.5/5.0
Disambiguation3/5

Most tools have clearly written descriptions, but several pairs overlap semantically: token_price/token_report, latest_filings/recent_filings, and institutional_holdings/who_holds/activist_stakes all require careful reading to pick the right one. The overlap is not severe enough for a 2, but it is still more than the occasional confusion.

Naming Consistency3/5

Names are consistently snake_case and mostly descriptive, but the set does not follow one naming convention. It mixes noun phrases (crop_data, token_report, insider_trades) with verb phrases (lookup_company, compare_filings, verify_financial_claim), and pairs like latest_filings/recent_filings create avoidable confusion.

Tool Count2/5

31 tools is too many for what is nominally an SEC Filings server, and the scope sprawls into unrelated domains such as EVM gas, tokens, prediction markets, crop data, and x402 auditing. The count does not feel earned by a coherent workflow; it feels like an uncurated bundle of endpoints.

Completeness3/5

The SEC filing workflow is reasonably covered: company lookup, search, latest/recent filings, section extraction, 8-K events, comparisons, ownership filings, and XBRL financial checks are all present. However, there is no full-filing retrieval endpoint, no deep company financial history beyond a single concept, and many non-SEC subdomains are only one-off data points, so the overall surface is still incomplete.