Skip to main content
Glama

Filings

akkru_filings
Read-onlyIdempotent

The financial reports (10-K, 10-Q, 20-F, 40-F and their Korean, Japanese, Chinese and European equivalents) on file for a company.

  • list: one company's filings for one fiscal year, with each filing's id, form, quarter, registrant, fact count, whether it has an Excel file (has_excel), and a note when an amendment was merged in. 10 credits.

  • excel: a download URL for one filing's Excel file, valid for one hour. 300 credits. Older years and some markets depend on your plan.

Input Schema

NameRequiredDescriptionDefault
actionYesWhat to do; each action is described in the tool description.
detailNoResponse detail, same price at every level: "full" (default) returns everything; "light" leaves out the bulkiest fields, such as breakdown lists; "minimal" returns only the values and what identifies them, without sources or calculation details. Every action takes it; a call without detail levels ignores it. Try "light" or "minimal" for shorter replies that use less context and fewer tokens.
tickerNo(list, excel) Company ticker, e.g. "AAPL" (US), "000100" (Korea), "1332" (Japan), "VIRI_F" (Europe), "600519_CN" (China A-share); any symbol the company has traded under.
quarterNo(list, excel) "FY", "Q1", "Q2", "Q3" or "Q4". list: filters the list, omit for every quarter; excel: needed only when the fiscal year has several filings of the form; the error then lists the quarters on file.
filing_idNo(excel) Filing id from akkru_filings action "list". Name the filing with filing_id, or with ticker and fiscal_year, not both.
form_typeNo(list, excel) Form: "10-K", "10-Q", "20-F" or "40-F" (Korean, Japanese, Chinese and European filings use "10-K" for annual and "10-Q" for interim reports). list: filters the list, omit for every form; excel: defaults to "10-K".
as_of_dateNo(list) Date "YYYY-MM-DD" (not in the future): only what had been filed by that day counts. Default: no cutoff.
fiscal_yearNo(list, excel) Fiscal year of the filing (1990-2100).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / as_of_date
      Added value: +{
      +  "description": "(list) Date \"YYYY-MM-DD\" (not in the future): only what had been filed by that day counts. Default: no cutoff.",
      +  "format": "date",
      +  "type": "string"
      +}
  2. Added

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive behavior, and the description adds substantive context beyond them: per-action credit costs (10 vs 300), a one-hour expiry on the Excel download URL, the presence of a has_excel flag, amendment-merge notes, and the caveat that older years and some markets depend on the plan. These are exactly the operational facts an agent cannot infer from the schema.

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?

One framing sentence followed by two action bullets with costs inline — dense and front-loaded, with no filler. The plan caveat is tucked at the end where it belongs, though the action bullets are terse enough that the fiscal-year scoping assumption has to be inferred.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does so for both actions: it enumerates list fields (id, form, quarter, registrant, fact count, has_excel, amendment note) and describes the Excel response as a time-limited URL. Minor gap: it says list covers 'one fiscal year' while fiscal_year is not a required parameter and no default or error behavior is stated for omitting it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already explains every parameter, including the alternative of naming a filing by filing_id versus ticker plus fiscal_year. The description adds little parameter-level meaning beyond noting that results are confined to a single fiscal year, so the baseline of 3 applies.

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?

States a specific resource (regulatory filings: 10-K, 10-Q, 20-F, 40-F plus non-US equivalents) and splits it into two clearly named actions, 'list' and 'excel'. An agent can tell this apart from akkru_statements or akkru_facts by resource, though no sibling is named explicitly.

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?

Gives per-action guidance: 'list' for one company's filings for a fiscal year, 'excel' when a downloadable spreadsheet is needed, and the error-listing behavior when a fiscal year has multiple filings of a form. It does not say when to prefer this over sibling tools like akkru_statements, so the routing between tools is left implicit.

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.

Resources