Skip to main content
Glama
cliwant

mcp-sam-gov

by cliwant

edgar_company_concept

Read-only

Retrieve the complete reported time-series for a specific financial concept (e.g., Assets) of an SEC filer, including amendments and restatements, to analyze trends and revisions over time.

Instructions

One filer × one XBRL concept × the COMPLETE reported time-series (keyless, from data.sec.gov companyconcept). The focused financial-TREND / entity-vetting primitive BETWEEN edgar_company_facts (many curated concepts for one filer) and edgar_xbrl_frames (one concept across ALL filers for one period) — 'track THIS filer's Assets/Revenues/NetIncomeLoss OVER TIME, and was it ever revised?'. Input cikOrTicker (CIK or resolvable ticker/name), concept (EXACT alnum XBRL tag, e.g. 'Assets'), optional taxonomy (us-gaap|dei|ifrs-full, def us-gaap), unit (CLIENT-SIDE key filter), form/fy (client-side), canonicalOnly (def false), limit/offset. Returns { found, cik, entityName, taxonomy, concept, label, description, unitsAvailable:[{unit,count}], rows:[{ unit, start, end, val, accn, fy, fp, form, filed, frame, canonical }] }. HONESTY: (M1) period identity is the (start,end) PAIR — every row carries start (null for INSTANT concepts, the ISO date for DURATION/flow concepts); the SAME end with a DIFFERENT start is a different-duration fact (a 3-month quarter vs the 12-month year), NOT a revision — a revision is only multiple rows sharing the same (start,end) with a differing accn/filed/val. DEFAULT returns ALL rows incl. the amendment/restatement history + a per-row canonical (frame-tagged = SEC's consolidated value); canonicalOnly:true dedups to one canonical row per (unit,start,end), fully disclosed, never a silent drop. Every row is unit-tagged (a USD amount is NEVER conflated with a share count); unitsAvailable discloses ALL units with their RAW counts even under a unit filter; val is null-never-0. A bad CIK/taxonomy/concept ⇒ upstream 404 ⇒ found:false (NEVER a fabricated val:0); a 5xx/timeout/non-JSON/units-shape-drift THROWS; a unit not present ⇒ honest empty + the available-units note (unit is CLIENT-SIDE, not a path segment). cik/taxonomy/concept are validated path segments (regex+enum, re-checked pre-fetch) — no injection surface. NOTE: EDGAR keys on CIK, NOT SAM UEI/DUNS — there is no authoritative CIK↔UEI join.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fyNoOptional CLIENT-SIDE filter: keep only rows whose fiscal year `fy` equals this integer (e.g. 2023).
formNoOptional CLIENT-SIDE filter: case-insensitive EXACT match on a row's `form` (e.g. '10-K' for annual values only, '10-Q' for quarterly).
unitNoOptional CLIENT-SIDE filter on the returned units{} keys (NOT a path segment — 'USD', 'shares', 'USD/shares', 'EUR', 'pure'). Restricts rows to that unit but STILL discloses the other units via unitsAvailable + a note. A unit not present ⇒ 0 rows + the available-units note (never a fabricated pick).
limitNoCLIENT-SIDE page size over the already-fully-fetched, (unit,start,end)-keyed time-series (1..1000, default 100). Does NOT reduce the upstream fetch (SEC does not paginate companyconcept); page via _meta.pagination.nextOffset.
offsetNo0-based client-side offset into the filtered time-series (default 0).
conceptYesXBRL concept tag — EXACT, alphanumeric CamelCase (e.g. 'Assets', 'Revenues', 'NetIncomeLoss', 'Liabilities'). A tag the filer never reported ⇒ upstream 404 ⇒ found:false (never a fabricated 0).
taxonomyNoXBRL taxonomy namespace (a fixed enum — the SSRF guard for this segment): 'us-gaap' (financial statements, default), 'dei' (entity/document info, e.g. EntityCommonStockSharesOutstanding), or 'ifrs-full' (IFRS filers, e.g. a foreign private issuer). Live-confirmed members only.
cikOrTickerYesA 10-digit (or unpadded) SEC CIK, or a ticker/company-name resolvable via company_tickers.json (e.g. '320193', 'CIK0000320193', 'AAPL').
canonicalOnlyNoWhen true, reduce to ONE row per distinct (unit,start,end) period — the frame-tagged canonical value, or (for a not-yet-consolidated period) the latest-filed row (marked canonical:false). SUPERSEDED/amendment rows are REMOVED (fully disclosed via a note). Default false ⇒ ALL rows incl. the amendment/restatement history. A same-`end` different-`start` pair is a DIFFERENT period (both kept), NOT a duplicate.
Behavior5/5

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

Annotations declare readOnlyHint and openWorldHint. The description goes far beyond by detailing period identity, revision detection, null vs. 0 handling, error behaviors (404 vs. 5xx vs. throw), validation, injection prevention, and the 'canonicalOnly' dedup logic. No contradictions with annotations.

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 comprehensive but verbose. It is front-loaded with purpose and relationship, then dives into extensive 'HONESTY' details. While every sentence adds value, the length could be slightly reduced for quicker parsing. However, given complexity, the structure is logical.

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?

The description covers the full return structure, error handling, client-side filtering, period identity, and revision semantics. It addresses edge cases and provides sufficient detail for an agent to invoke the tool correctly, even without an output schema. All 9 parameters are well-documented in context.

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?

Schema coverage is 100%, but the description adds substantial context: explains how each parameter interacts with the upstream API (e.g., 'unit' as client-side filter, 'canonicalOnly' deduplication), clarifies edge cases (unit not present yields empty result with note), and enriches understanding of parameters like 'fy' and 'form' as client-side filters.

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 clearly identifies the tool as fetching a complete time-series for one filer and one XBRL concept. It explicitly distinguishes itself from siblings `edgar_company_facts` and `edgar_xbrl_frames` by positioning as a focused primitive for tracking trends and revisions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage context: 'track THIS filer's Assets/Revenues/NetIncomeLoss OVER TIME, and was it ever revised?' It also clarifies the middle position between its two sibling tools, implying when to use this vs. the others. It includes detailed behavioral notes that serve as guidelines for interpreting results.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cliwant/mcp-sam-gov'

If you have feedback or need assistance with the MCP directory API, please join our Discord server